The Arsenal Files 2/The Arsenal Files 2 (Arsenal Computer).ISO/os2/os2dc1.exe/ENGLISH/OS2BOOK.INF

OS/2 Help File | 1994-03-29 | 636.5 KB | 10,161 lines

ΓòÉΓòÉΓòÉ 1. READ ME FIRST ! ΓòÉΓòÉΓòÉ

We Need Your Comments

This online version of the NetWare Client for OS/2 User Guide is a new product
from Novell's Technical Publications Department.

Please give us your comments. Print this page and FAX or mail it to:

     Novell, Inc.
     Technical Publications
     MS C-23-1
     122 East 1700 South
     Provo, UT 84606
     FAX [phone]

How useful are the following resources in answering your questions about the
setup or configuration of the NetWare Client for OS/2?

Least Useful    Most Useful

 1  2  3  4  6  7  8  9  10        The hardcopy NetWare Client for OS/2 User
                                   Guide.

 1  2  3  4  6  7  8  9  10        This online NetWare Client for OS/2 User
                                   Guide in native OS/2 format.

 1  2  3  4  6  7  8  9  10        ElectroText(TM) (Novell's online
                                   documentation in MS Windows format)

 1  2  3  4  6  7  8  9  10        The Help screens for the various utilites
                                   (i.e. NWADMIN, NWTOOLS, INSTALL)

 Please comment on whether you like this online NetWare Client for OS/2 User
 Guide and how you would like to see it improved.


ΓòÉΓòÉΓòÉ 2. NetWare Client for OS/2 User Guide ΓòÉΓòÉΓòÉ

NetWare Client for OS/2 User Guide

Disclaimer

Novell, Inc. makes no representations or warranties with respect to the
contents or use of this manual, and specifically disclaims any express or
implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make
changes to its content, at any time, without obligation to notify any person or
entity of such revisions or changes.

Further, Novell, Inc. makes no representations or warranties with respect to
any NetWare software, and specifically disclaims any express or implied
warranties of merchantability or fitness for any particular purpose. Further,
Novell, Inc. reserves the right to make changes to any and all parts of NetWare
software, at any time, without any obligation to notify any person or entity of
such changes.

Trademarks Novell, Inc. has made every effort to supply trademark information
about company names, products, and services mentioned in this manual. The
following list of trademarks was derived from various sources.

     NetWare and Novell are registered trademarks of Novell, Inc.
     Internetwork Packet Exchange (IPX), LAN WorkPlace, MLID, NE1000, NE2000,
     NetWare Client, NetWare Core Protocol (NCP), NetWare Directory Services
     (NDS), NetWare Tools, Open Data-Link Interface (ODI), Packet Burst, SFT
     III, SPX, and Technical Support Alliance (TSA) are trademarks of Novell,
     Inc.
     NetWire is a registered service mark of Novell, Inc.
     UNIX is a registered trademark of UNIX System Laboratories, Inc., a wholly
     owned subsidiary of Novell, Inc.
     IBM and OS/2 are registered trademarks of International Business Machines
     Corporation.

 Copyright 1994 Novell, Inc. All rights reserved. No part of this publication
 may be reporduced, photocopied, stored on a retrieval system, or transmitted
 without the express written consent of the publisher.

 NetWare Client for OS/2 User Guide
 March 1994


ΓòÉΓòÉΓòÉ 3. Introduction ΓòÉΓòÉΓòÉ

Introduction

Topics

NetWare Client for OS/2 Features

Information for DOS Users Migrating to OS/2

NetWare 2 and 3 Users Upgrading to NetWare 4


ΓòÉΓòÉΓòÉ 3.1. NetWare Client for OS/2 Features ΓòÉΓòÉΓòÉ

NetWare Client for OS/2 Features

NetWare Client(TM) for OS/2 workstation software enables OS/2 workstations to
access NetWare servers. After you install NetWare Client for OS/2, you can
connect to a NetWare network and perform basic network tasks.

NetWare Client for OS/2

 Γûá Supports both NetWare 3 and NetWare 4 servers.
 Γûá Offers Remote Program Load (RPL) workstation access.
 Γûá Supports SFTIII(TM) for both the client and SPX(TM).
 Γûá Provides access for up to 9 parallel ports.
 Γûá Supports OS/2, DOS/MS Windows private sessions, DOS/MS Windows global
 sessions, VMBoot private sessions, and VMBoot global sessions for NetWare 3.


ΓòÉΓòÉΓòÉ 3.2. Information for DOS Users Migrating to OS/2 ΓòÉΓòÉΓòÉ

Information for DOS Users Migrating to OS/2

This section explains the basic differences between using NetWare from an OS/2
workstation and using NetWare from a DOS workstation.

ODI LAN Drivers

ODI LAN drivers used by NetWare Client for OS/2 serve the same purpose and
follow the same technical specifications as ODI LAN drivers used by NetWare
Client for DOS and MS Windows.

OS/2 ODI drivers have the same filenames as DOS ODI drivers, except they have a
.SYS extension instead of a .COM extension.

OS/2 ODI drivers are loaded in the CONFIG.SYS file, whereas the DOS ODI drivers
are loaded in the AUTOEXEC.BAT file.

Important For OS/2, network drivers and device drivers are always loaded in
CONFIG.SYS. AUTOEXEC.BAT is not used in OS/2.

IPX

NetWare Client for OS/2 uses the IPX protocol to connect to NetWare servers.
For OS/2, IPX is a .SYS file and is loaded in the CONFIG.SYS file with the
other NetWare drivers.

If you use virtual DOS sessions in OS/2, those sessions use a virtualized
version of IPX, called VIPX. VIPX talks to IPX to allow DOS sessions to
communicate on the network.

In a virtual DOS session, you run VIPX provided with NetWare Client for OS/2
rather than the IPX provided with NetWare Client for DOS and MS Windows.

When you install NetWare Client for OS/2, lines to load IPX and VIPX are loaded
automatically in CONFIG.SYS.

NET.CFG File

The NET.CFG file serves the same purpose under OS/2 as it does under DOS: it
allows you to configure your network connection.

NET.CFG for OS/2 has options and settings just as NET.CFG for DOS. However,
options and settings are somewhat different. Some of them use different syntax
and configure different software components.

Because of this, you cannot just copy NET.CFG from a DOS workstation to an OS/2
workstation and expect it to work. Instead, create a new NET.CFG file for the
OS/2 workstation if you have nondefault configurations.

In OS/2, NET.CFG is a text file that can be created or edited with the NetWare
Client for OS/2 installation program. This program contains online help showing
the syntax of all options. (NET.CFG can be edited with a text editor as well.)

You can put DOS and OS/2 NET.CFG options into the same NET.CFG file on your
OS/2 workstation. Then when you run a private virtual DOS session, NetWare
Client for DOS and MS Windows will use the DOS options. NetWare Client for OS/2
ignores the DOS options.

Logging In

When you boot your workstation, NetWare Client for OS/2 maps drive L: as the
default drive to the SYS:LOGIN directory (configurable in NET.CFG).

This mapping combines with the L:\OS2 mapping that the NetWare Client for OS/2
installation puts in your path, and gives you a search path to the login
utilities. (You don't have to change to drive L: to log in.)

NetWare Client for OS/2 does not support a LASTDRIVE setting in CONFIG.SYS.

You can log in from any OS/2 session or the desktop, and your login applies to
all other OS/2 sessions. For example, if you logged in from the command line of
an OS/2 session and then you went to the desktop and used NetWare Tools(TM),
you would already be logged in to the same location you logged in to at the
command line.

Important The attachment from NetWare Tools does not run a login script. To
execute a login script, run LOGIN from the command line.

You can also log in from virtual DOS sessions running on OS/2. You can set up
virtual sessions so that each session can support its own login to the network
(private sessions) or so that all sessions - including OS/2 - share a single
login to the network (global sessions).

Network support from virtual DOS sessions works much the same as network
support from regular DOS workstations. You use a NETX.EXE shell and a
virtualized version of IPX, called VIPX.SYS.

Important When logging in from virtual sessions, you do not have NetWare
Directory Services (NDS) support. This means that you can only log in to a
NetWare 4 network that has bindery emulation.

Utilities

NetWare utilities for OS/2 have the same names as NetWare utilities for DOS.
However, OS/2 utilities are different executable files than DOS utilities.

NetWare OS/2 utilities are in the SYS:PUBLIC\OS2 and SYS:LOGIN\OS2 directories
so they do not overlap with NetWare utilities for DOS in the SYS:PUBLIC and
SYS:LOGIN directories. If you run a NetWare DOS utility in OS/2, OS/2 will try
to start a DOS session to run that utility.

The following utility files are available from the NetWare Client for OS/2
diskettes:

 Γûá CX.EXE
 Γûá MAP.EXE
 Γûá NETX.EXE
 Γûá NLIST.EXE
 Γûá NPRINTER.EXE

 Drive Mappings and Search Drives

 Search drives are not used in OS/2. Instead, the search functionality to
 NetWare utilities and other programs is set up with PATH, LIBPATH, and DPATH
 statements in CONFIG.SYS.

 Mapping to Login Utilities

 When you boot your workstation, NetWare Client for OS/2 connects to the first
 server it finds and maps drive L: to the SYS:LOGIN directory (configurable in
 NET.CFG).

 This mapping combines with the L:\OS2 mapping that the NetWare Client for OS/2
 installation puts in your path and gives you a search path to the login
 utilities.

 Once you log in, drive L: disappears.

 Mapping to Public Utilities

 The NetWare default login script for OS/2 contains the following line mapping
 drive P: to public utilities:

 MAP P:=SYS:PUBLIC

 This mapping combines with the P:\OS2 mapping that the NetWare Client for OS/2
 installation puts in your path and gives you a search path to the
 SYS:PUBLIC\OS2 directory. When you type a utility name from any drive other
 than drive P:, the utility from the \OS2 subdirectory is executed.

 Important Even though your search path gets set to SYS:PUBLIC\OS2 by default,
 drive P: stays mapped to SYS:PUBLIC.

 If you change to drive P:, you are in SYS:PUBLIC, not SYS:PUBLIC\OS2. If you
 type a utility name at drive P:, the DOS version of the utility is executed.

 Other Protocols

 NetWare Client for OS/2 provides support for the following protocols:

  IPX
  SPX
  Named Pipes
  NetBIOS

 These protocols support OS/2 client workstations and servers on a distributed
 application network. SPX supports some NetWare printing utilities.

 DOS client workstations running DOS Named Pipes or NetBIOS can connect to OS/2
 application servers running Named Pipes or NetBIOS.

 You can select support for these protocols in the NetWare Client for OS/2
 installation program. The protocols you select are loaded into CONFIG.SYS.

 To access SPX, Named Pipes, and NetBIOS support from virtual DOS and MS
 Windows sessions on OS/2, you must load some programs provided with NetWare
 Client for OS/2.


ΓòÉΓòÉΓòÉ 3.3. NetWare 2 and 3 Users Upgrading to NetWare 4 ΓòÉΓòÉΓòÉ

NetWare 2 and 3 Users Upgrading to NetWare 4

Significant changes have been made in the following areas:

 Γûá Default frame type for Ethernet ODI drivers
 Γûá Selecting a preferred server
 Γûá Logging in to the network
 Γûá Login scripts
 Γûá Mappings in the default login script
 Γûá Mapping to the public utilities
 Γûá Virtual DOS and MS Windows sessions

 Default Frame Type for Ethernet ODI Drivers

 The default frame type for Ethernet ODI drivers has changed. In NetWare 2 and
 3, Ethernet drivers defaulted to the Ethernet 802.3 frame type. In NetWare 4,
 they default to the Ethernet 802.2 frame type.

 NetWare 4 server drivers for Ethernet also default to the Ethernet 802.2 frame
 type. Servers and workstations use the same frame type to communicate with
 each other.

 Routers must also support the frame type or your workstation can't get a
 connection. Some routers on your network may not support the Ethernet 802.2
 frame type default.

 Important If you use the Ethernet 802.2 frame type on your workstation, it
 can't connect to a network expecting the Ethernet 802.3 frame type.

 To eliminate a potential conflict, you can define both frame types (Ethernet
 802.2 and Ethernet 802.3) on your network.

 For the workstation, define frame types in NET.CFG. Include a line similar to
 the following, replacing NE2000 with the name of your ODI driver:

     link driver ne2000
        frame ethernet_802.2
        frame ethernet_802.3

 The first frame type defined is the only one used for the initial "Get Nearest
 Server" request.

 Therefore, if some of your servers use only one frame type, such as Ethernet
 802.3, put that frame type first. That way your workstation can make a default
 connection to those servers.

 Selecting a Preferred Server

 NetWare Directory Services (NDS) provided in NetWare 4 uses trees and contexts
 rather than servers to identify what you log in to.

 A new NET.CFG setting called preferred tree has been created. Use preferred
 tree in NetWare 4 the same way you used preferred server in NetWare 2 and 3
 (except you specify a tree name rather than a server name).

 Use preferred tree only for sites that have more than one Directory tree.

 For example, to initially connect to a tree called Novell, add the following
 lines in your NET.CFG file:

     netware requester
        preferred tree novell

 Preferred server is still a supported setting; however, the syntax has
 changed. You now type the word server as well as a server name. For example:

     netware requester
        preferred server fs1

 Regardless of your NET.CFG file, NetWare Client for OS/2 first tries to
 establish a default connection to an NDS server. This connection is made to
 the first NDS server that responds.

 If NetWare Client for OS/2 succeeds in connecting to an NDS server, it then
 looks for a preferred tree. Once it connects to a preferred tree, it checks to
 see if you have a preferred server specified. If that server is in the current
 context, it connects to that server.

 If NetWare Client for OS/2 can't connect to an NDS server, it tries to
 establish a default connection to a bindery server.

 If it connects to a bindery server, it first looks for a preferred server,
 ignoring any preferred tree you specified.

 Logging In to the Network

 When you log in under NetWare 4, you log in to a Directory tree rather than a
 server. This means you log in to a location in the Directory (called a
 context) rather than to a server.

 Logging in from the OS/2 Command Line

 You use the NetWare 4 LOGIN utility to log in from a command line. This
 utility is located in the SYS:LOGIN\OS2 directory.

 With LOGIN, you can specify a context in the Directory tree. A context
 includes a User object and an Organization object.

 For example, to log in to a NetWare 4 network, type

 LOGIN .JOHN.SALES_MKTG

 JOHN is the User object. SALES_MKTG is the Organization object.

 You can use the NetWare 4 LOGIN utility to log in to NetWare 3.1x servers. Use
 the same login syntax you used for NetWare 3.1x LOGIN and add the /B option.
 For example, type

 LOGIN SALES_MKTG/NANCY /B

 NetWare Tools Attach Feature

 The attachment from NetWare Tools does not run a login script. You must run
 LOGIN from the command line to execute a login script.

 Mappings in Default Login Script

 In NetWare 2 and 3, a default login script was executed if you had no other
 login script.

 In NetWare 4, the default login script still exists. Unless the network
 supervisor specifies otherwise, using a parameter in the system login script,
 it is executed when a user login script does not exist.

 Also, search drives aren't used in OS/2. Instead, the search functionality to
 the NetWare utilities and other programs is set up with PATH, LIBPATH, and
 DPATH statements in CONFIG.SYS.

 The NetWare 4 default login script contains the following line mapping drive
 P: to the utilities:

 MAP P:=SYS:PUBLIC

 This mapping combines with the P:\OS2 mapping the NetWare Client for OS/2
 installation puts in your path and gives you a search path to the
 SYS:PUBLIC\OS2 directory.

 When you execute a utility from any drive other than drive P:, the utility
 from the \OS2 subdirectory is executed.

 Important Even though your search path is set to SYS:PUBLIC\OS2 by default,
 drive P: stays mapped to SYS:PUBLIC.

 If you change to drive P:, you are in SYS:PUBLIC, not SYS:PUBLIC\OS2. If you
 execute a utility at drive P:, the DOS version of the utility is executed.

 Mapping to the Public Utilities

 When setting up system or user login scripts for OS/2 users, always map drive
 P: to SYS:PUBLIC, as shown:

 MAP P:=SYS:PUBLIC

 Why Drive P:

 This mapping combines with the P:\OS2 directory the NetWare Client for OS/2
 installation puts in your path. The combination gives you a search path to
 SYS:PUBLIC\OS2.

 If you use another mapping besides P:, that mapping will not combine with the
 P:\OS2 directory that NetWare Client for OS/2 puts in your path, leaving you
 without a search path to the utilities.

 When you execute a utility from a drive other than drive P:, the utility from
 the \OS2 subdirectory is executed.

 Why SYS:PUBLIC and not SYS:PUBLIC\OS2

 Important Do not map drive P: to SYS:PUBLIC\OS2.

 The NetWare utilities for OS/2 need to find language-specific files in the
 parent directory of the directory they are executed from.

 For example, a utility executed from SYS:PUBLIC\OS2 expects to find an \NLS
 subdirectory in SYS:PUBLIC.

 If the drive allowing access to the utilities is mapped to SYS:PUBLIC\OS2,
 that directory becomes the root of the drive, since all network drives mapped
 in OS/2 are root drives.

 This means that OS/2 doesn't recognize a parent directory for utilities. When
 utilities try to locate the \NLS subdirectory in their own parent directory,
 OS/2 returns an error and your utility won't run.

 Important If you change to drive P:, you are in SYS:PUBLIC, not
 SYS:PUBLIC\OS2. If you execute a utility from drive P:, the DOS version of the
 utility is executed.

 Login Scripts

 The How To Edit Login Scripts for Each Type of Session table shows the login
 script executed the type of login and how to edit the login script.

 Login Script Commands Not Supported in OS/2

 OS/2 login scripts do not support the following commands:

 COMSPEC
 DOS BREAK
 MACHINE NAME

 The following commands have unique functions or limitations when used in OS/2
 login scripts.

 Command   Limitation

 EXIT      Does not support the filename parameter.

 DRIVE     Sets the default for the login process only.

 INCLUDE   If you use an include statement, you must specify a Universal Naming
           Convention (UNC) pathname for the file to be included. For example,
           if the file to be included is called INCLUDE.TXT and it is located
           on NetWare server FS1, volume SYS:, directory PUBLIC, the include
           statement should read: INCLUDE \\FS1\SYS\PUBLIC\INCLUDE.TXT

 MAP       You cannot map search drives in OS/2. The same functionality is
           provided by using the OS/2 PATH and DPATH commands. See the OS/2
           documentation.

 SET       Sets the environment variable for the login process only. Spawned
           processes inherit the variable, but the variable disappears when
           LOGIN terminates.

 Virtual DOS and MS Windows Sessions

 With NetWare Client for OS/2, you have full NetWare 3.1x functionality from
 both private and global sessions. However, you don't have NDS functionality
 (provided with NetWare 4).

 This means you can run NetWare 4 DOS utilities from a DOS session, but you
 can't access NetWare Directory Services. To a NetWare 4 server, your client
 appears to be a NetWare 3.1x bindery emulation client.

 To obtain NDS functionality, boot from a different DOS kernel than the one
 included with OS/2 and load the NetWare Client for DOS and MS Windows
 software.

 Boot from a real DOS kernel by using the DOS_STARTUP_DRIVE setting. The OS/2
 online Master Help Index explains how.

 Sessions booted from a real DOS kernel can have private or global support.
 Global sessions booted with a real DOS kernel have NetWare 3.1x support.
 Private sessions booted with a real DOS kernel can have NetWare 4 support if
 you load the NetWare Client for DOS and MS Windows.

 NetWare support in DOS/Windows sessions


ΓòÉΓòÉΓòÉ 3.3.1. How To Edit Login Scripts for Each Type of Session ΓòÉΓòÉΓòÉ

How To Edit Login Scripts for Each Type of Session


 If you log in from   Login script run     How login script is edited
 ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
 OS/2 session         NetWare 4 Login      With the NetWare Administrator
                      Profile object       for OS/2 utility.
 ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
 OS/2 session         NetWare 3.12         Use SYSCON.
 ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
 Private DOS/MS       NetWare 3.1x DOS     From a text editor. Edit the
 Windows session      login script         SYS:MAIL\userID\LOGIN file or
                                           use a NetWare 3.1x utility,
                                           such as SYSCON.
 ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
 Global DOS/MS        NetWare 3.1x DOS     From a text editor. Edit the
 Windows session      login script         SYS:MAIL\userID\LOGIN file or
                                           use a NetWare 3.1x utility,
                                           such as SYSCON.
 ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
 Global session       NetWare 3.1x DOS     From a text editor. Edit the
 booted from real DOS login script         SYS:MAIL\userID\LOGIN file or
 kernel and running                        use a NetWare 3.1x utility,
 NETX.EXE                                  such as SYSCON.
 ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
 Private session      NetWare 4 Login      With the NetWare Administrator
 booted from real DOS Profile object       for OS/2 utility.
 kernel and running
 NetWare Client for
 DOS and MS Windows


ΓòÉΓòÉΓòÉ 4. Preparing Hardware ΓòÉΓòÉΓòÉ

Preparing Hardware

Hardware Prerequisites

The following checklist will help you prepare your workstation for installing
NetWare Client for OS/2.

Checklist

      An IBM personal computer (or compatible) with a 386 (SX or DX)
     processor. OS/2 2.x operates only with 386 (SX and DX) processors and
     above because of its 32-bit architecture

      A hard disk with 3 MB of free storage for NetWare Client for OS/2 files

      8 MB of RAM

      A 1 to 1.44MB 3.5-inch diskette drive

      If you want to use Remote Program Load (RPL),a Remote Reset PROM
     inserted in each RPL workstation

      A mouse or compatible pointing device

      A network board installed in your workstation

      A VGA monitor

 Network Cabling

 Each type of network board requires unique cabling. For requirements, see the
 manufacturer's documentation packaged with the board.

 Important Token ring network boards must have a physical connection to the MAU
 before you install NetWare Client for OS/2. Otherwise, the TOKEN driver will
 not load.

 Determining Network Board Settings

 The NetWare Client for OS/2 installation program requires specific information
 about the network board in your workstation.

 Before installing NetWare Client for OS/2, record the values for the following
 settings:

 Checklist

      Hardware interrupt

     In most cases, you can use interrupt line 3 or interrupt line 5 for your
     network board. If neither interrupt line 3 nor interrupt line 5 is
     available, see the manufacturer's documentation.

     Note:  We recommend that you don't use interrupt line 2. It may interfere
     with the VGA adapter.

      Base I/O port

     Each hardware device included in your workstation must have a different
     base I/O port setting. For more information, see the manufacturer's
     documentation.

      Frame type

     All workstations and servers using a single network address must use the
     same frame type. The default for Novell ODI drivers is 802.2.

      Other settings

     Other settings unique to the network board installed in your workstation.
     (See the documentation provided with your network board.)

 Important In most cases, leave your network board set to the factory settings.
 If you need to change the default settings, see the manufacturer's
 documentation.

 You can obtain setting information for your network board by using the
 following procedures.

 Finding board settings

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  ΓöéIf you have     Then                                         Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéEISA or MCA     Run the computer's setup or reference        Γöé
  Γöénetwork boards  program. This program will list the values   Γöé
  Γöé                for your network board settings.             Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéISA network     Physically view the network board to obtain  Γöé
  Γöéboards          the specific settings. The documentation     Γöé
  Γöé                provided with your network board will direct Γöé
  Γöé                you where to locate each value.              Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 5. Installing NetWare Client for OS/2 ΓòÉΓòÉΓòÉ

Installing NetWare Client for OS/2

Topic

Installation Overview

Installing NetWare Client for OS/2 from Diskettes

Installing NetWare Client for OS/2 from CD-ROM

Upgrading NetWare Client for OS/2 from a Network Directory


ΓòÉΓòÉΓòÉ 5.1. Installation Overview ΓòÉΓòÉΓòÉ

Installation Overview

Four things happen when you install NetWare Client for OS/2:

     Γûá A directory is created on your workstation

     Γûá Files are copied

     Γûá The Novell group icon is created

     Γûá The CONFIG.SYS file is modified

 A Directory Is Created on Your Workstation

 By default, a \NETWARE directory is created in the root of the drive from
 which you boot OS/2. (If you specify another directory, it is created.)

 Files Are Copied

 All NetWare Client for OS/2 files are copied to the directory specified during
 installation. You can change your settings later without copying additional
 files from the WSOS2_1 diskette. Six kinds of files are copied:

 Γûá NetWare Client for OS/2 program files
 Γûá DLL files (Dynamic Link Libraries) for OS/2
 Γûá DLL file for MS Windows
 Γûá Network board drivers
 Γûá Utility files (INSTALL, NPRINTER, NWTOOLS, LOGIN, NLIST, MAP, CX, OS2_TSA)
 Γûá Unicode tables

 Most files on the diskette are compressed. The installation program
 decompresses them. To decompress a file, use the NWUNPACK utility on the
 diskette. Type NWUNPACK and the target directory, followed by the name of a
 file.

 Important If you install NetWare Client for OS/2 on an OS/2 for Windows
 workstation, the files are copied to the WINDOWS/SYSTEM directory.

 The Novell Group Icon Is Created

 A group icon called Novell is created on the OS/2 desktop. This group contains

 Γûá The NetWare Client for OS/2 installation program
 Γûá NetWare Tools
 Γûá The NPRINTER remote printing utility
 Γûá The OS2_TSA program

 The CONFIG.SYS File Is Modified

 The previous version of CONFIG.SYS is automatically saved as CONFIG.BAK.

 The NETWARE directory (or the directory you specify) is included at the end of
 the PATH, LIBPATH, and DPATH statements so that OS/2 can find the NetWare
 Client for OS/2 files. Based on the ODI driver and settings you choose, the
 NetWare Client for OS/2 section of CONFIG.SYS includes lines loading NetWare
 Client for OS/2 components. This section is identified by comment lines before
 and after.

 Warning Don't delete the comment lines before and after the NetWare Client for
 OS/2 lines. Everything between these comments is deleted and rewritten when
 you use the installation program to edit CONFIG.SYS.

 Important Make a backup copy of CONFIG.SYS after your NetWare Client for OS/2
 installation is completed. Other configuration programs, such as IBM's
 Extended Services, may rearrange CONFIG.SYS in such a way as to invalidate
 NetWare Client for OS/2.


ΓòÉΓòÉΓòÉ 5.2. Installing NetWare Client for OS/2 from Diskettes ΓòÉΓòÉΓòÉ

Installing NetWare Client for OS/2 from Diskettes

If you are installing NetWare Client for OS/2 from diskettes for the first
time, complete the following.

Prerequisites

Checklist

Γûá Have working copies of the following NetWare Client for OS/2 diskettes:

     Γûá WSOS2_1
     Γûá WSOS2 _2
     Γûá WSDRV_1

 Γûá (Optional) Have working copies of any NetWare compatible third-party network
 board drivers.

 Important You need a third-party MLID driver for the network board installed
 in your workstation if one is not provided with the NetWare Client for OS/2
 software. NetWare Client for OS/2 supports most network boards. If NetWare
 Client for OS/2 does not list a driver for your network board, check the
 packaging or contact the network board manufacturer to obtain a
 NetWare-compatible driver.

 Procedure 1. Go to the OS/2 desktop.

 2. Insert the diskette labeled WSOS2_1 into a disk drive.

 3. Choose the "Drive A" icon on the desktop.

     The "Drive A Tree View" window appears.

 4. From the "Drive A Tree View", select the "Drive A" icon.

 5. Select the "INSTALL.EXE" icon to load the installation program.

 6. From the "Installation" menu, select "Requester on workstation..."

     The "Set Target Directory" window appears.

 7. From the "Set Target Directory" window, set the appropriate path and source
 drive. Choose OK.

     The "Requester Installation" window appears.

 8.From the "Requester Installation" window, accept the default of "Edit
 CONFIG.SYS and Copy All Files" by choosing OK.

 NoteThe other three choices are for changing the initial installation of
 NetWare Client for OS/2.

     The "Step 1 - Choose the ODI LAN Driver" window appears.

 9. From the "Step 1 - Choose the ODI LAN Driver" window, select the
 appropriate driver.

     9a. Choose the arrow next to the "ODI LAN Driver" window.

     9b. Insert "WSDRV_1" in drive A: as instructed. Choose "OK".

     9c.Select the appropriate LAN Driver provided by NetWare Client for OS/2
     or a third-party vendor. Choose "Continue".

     The "Step 2 - Choose NetWare Support for DOS and Windows Applications"
     window appears.

 10. From the "Step 2 - Choose NetWare Support for DOS and Windows
 Applications" window, select IPX Support for DOS and MS Windows and Default
 NetWare Shell Support. Choose "Continue".

     For more information on available selections, choose "Help".

     The "Suggested Default Settings to AUTOEXEC.BAT" window appears.

 11. From the "Suggested Default Settings to AUTOEXEC.BAT" window, accept the
 default by choosing "Save".

     For more information on available selections, choose "Help".

 12. Select "No" when asked if you want to add files to another batch file.

     This window allows you to customize boot files for individual DOS
     sessions. Typically, all DOS sessions use the same boot file (i.e., the
     AUTOEXEC.BAT file).

 13. If prompted to change the DOS_LASTDRIVE setting, select "OK".

 Important Make sure your DOS_LASTDRIVE setting is correct upon completion of
 NetWare Client for OS/2 installation. See "Changing and Saving DOS and
 WIN-OS/2 Settings" in the OS/2 Master Help Index.

     The "Step 3 - Choose Optional Protocols" window appears.

 14. From the "Step 3 - Choose Optional Proctols" window, accept the defaults
 by choosing "Save".

     For more information on available selections, choose "Help".

     The "Save Changes to CONFIG.SYS" window appears.

 15. Choose "OK" to save the file as CONFIG.SYS. To save the file under a
 different name, edit the window.

     The "Copy ODI LAN Driver Files" window appears.

 16. From the "Copy ODI LAN Driver Files" window, accept the default by
 choosing OK.

     For more information on available selections, choose "Help".

     The "Copy Requester Files" window appears.

 17. From the "Copy Requester Files" window, choose Copy.

 18. To complete installation, follow instructions on your screen.

 19. Read the final screen that appears after installation for the latest
 information on the installation procedure.

 20. Configure your workstation.

     Detailed information on each configuration option is located in NET.CFG
     Options Reference

     Important For changes to take effect from your configuration, restart your
     workstation.


ΓòÉΓòÉΓòÉ 5.3. Installing NetWare Client for OS/2 from CD-ROM ΓòÉΓòÉΓòÉ

Installing NetWare Client for OS/2 from CD-ROM

You can use the NetWare server installation program on CD-ROM to copy
workstation installation files to the PUBLIC\CLIENT directory on volume SYS:.

Copying Client Installation Software from the CD-ROM to the Server

To copy NetWare Client for OS/2 installation software from the CD-ROM to the
server, follow the steps below.

Prerequsite

Checklist  Install the CD-ROM drive as a device on your workstation according
to the manufacturer's instructions.

Procedure 1. Log in.

2. Make a subdirectory named CLIENT under SYS:PUBLIC for the workstation
installation files.

3. Copy files from the CLIENT directory on the CD-ROM to SYS:PUBLIC\CLIENT by
typing either:

     NCOPY drive:\source path\*.* drive:\destination path /s/e/c

     or

     XCOPY drive:\source path\*.* drive:\destination path /s/e/v

 For example, type

     XCOPY D:\CLIENT\OS2\*.* H:\PUBLIC\CLIENT /s /e /v

 Important Don't use the COPY command for this procedure. The directory
 structure within each subdirectory must be maintained.

 noteYou can also set up your CD-ROM drive as a volume on your network. This
 allows you to run workstation installation programs directly from
 subdirectories under CLIENT on the CD-ROM.

 Creating Workstation Installation Diskettes from CD-ROM

 You can install the CD-ROM either as a local volume or as a network device.

 Procedure  1. Format high-density diskettes using the FORMAT command. You must
 format three diskettes for the NetWare Client for OS/2 installation.

 2. Go to the drive corresponding to the CD-ROM.

 3. Change to the CLIENT directory on the CD-ROM.

 4. Change to the OS/2 subdirectory.

 5. Set the "nwlanguage environment" variable by typing the following at the
 command line.

     SET NWLANGUAGE=language <Enter>

     Replace language with the appropriate language found in the NLS
     subdirectory under CLIENT\OS2.

 6. Type

     MAKEDISK drive_letter: language <Enter>

 For example, type either

     MAKEDISK A: ENGLISH <Enter>

     or

     MAKEDISK B: ENGLISH <Enter>

 MAKEDISK copies client installation files from the CD-ROM directory to the
 diskettes.

 7. Make a label each diskette with the following names:

 Diskette number     Label for OS/2
     1               WSOS2_1
     2               WSOS2_2
     3               WSDRV_1

 noteInclude the version number and date on each diskette label.

 8. Save these diskettes until after you have installed all NetWare
 workstations.


ΓòÉΓòÉΓòÉ 5.4. Upgrading NetWare Client for OS/2 from a Network Directory ΓòÉΓòÉΓòÉ

Upgrading NetWare Client for OS/2 from a Network Directory

Important This feature is only available on NetWare 3.12 and NetWare 4 servers.

The following checklist and procedures help set up your workstation for
installing NetWare workstation software from a network directory. It is the
quickest and easiest way to upgrade NetWare client software.

Prerequisites

Checklist  Γûá You must have a version of the NetWare Client for OS/2 software
running on your workstation.

Γûá A copy of the NetWare Client for OS/2 software must exist on your network.

Γûá You must be logged in.

Γûá Your workstation must have a drive mapped to the PUBLIC\CLIENT\OS2 directory
on volume SYS:.

Procedure

1. Map a drive to the PUBLIC\CLIENT\OS2 directory on volume SYS:.

2. Type INSTALL.

3. From the "Installation" menu, select "Requester on workstation..."

     The "Set Target Directory" window appears.

 4. From the "Set Target Directory" window, set the appropriate path and source
 drive. Choose "OK".

     The "Requester Installation" window appears.

 5. From the "Requester Installation" window, select the appropriate choice for
 your upgrade. Choose "OK".

     For more information on available selections, choose "Help".

     The "Step 1 - Choose the ODI LAN Driver" window appears.

 6. From the "Step 1 - Choose the ODI LAN Driver" window, select the
 appropriate driver.

     6a. Choose the arrow next to the "ODI LAN Driver" window.

     6b. Insert "WSDRV_1" in drive A: as instructed. Choose "OK".

     6c. Select the appropriate LAN Driver provided by NetWare Client for OS/2
     or a third-party vendor. Choose "Continue".

     The "Step 2 - Choose NetWare Support for DOS and Windows Applications"
     window appears.

 7. From the "Step 2 - Choose NetWare Support for DOS and Windows Applications"
 window, select IPX Support for DOS and Windows and Default NetWare Shell
 Support. Choose "Continue."

     For more information on available selections, choose "Help".

     The "Suggested Default Settings to AUTOEXEC.BAT" window appears.

 8. From the "Suggested Default Settings to AUTOEXEC.BAT" window, accept the
 default by choosing "Edit".

     For more information on available selections, choose "Help".

 9. When asked if you want to add files to another batch file, select "No".

     This window allows you to customize boot files for individual DOS
     sessions. Typically, all DOS sessions use the same boot file (i.e., the
     AUTOEXEC.BAT file).

 10. If prompted to change the DOS_LASTDRIVE setting, select "OK".

 Important Make sure your DOS_LASTDRIVE setting is correct upon completion of
 NetWare Client for OS/2 installation. See "Changing and Saving DOS and
 WIN-OS/2 Settings" in the OS/2 Master Help Index.

     The "Step 3 - Choose Optional Protocols" window appears.

 11. From the "Step 3 - Choose Optional Proctols" window, accept the defaults
 by choosing "Save."

     For more information on available selections, choose "Help".

     The "Save Changes to CONFIG.SYS" window appears.

 12. Choose "OK" to save the file as CONFIG.SYS. To save the file under a
 different name, edit the window.

     The "Copy ODI LAN Driver Files" window appears.

 13. From the "Copy ODI LAN Driver Files" window, accept the default by
 choosing "OK."

     For more information on available selections, choose "Help".

     The "Copy Requester Files" window appears.

 14. From the "Copy Requester Files" window, choose "Copy."

 15. To complete installation, follow the instructions on your screen.

 16. Read the final screen that appears after installation for the latest
 information on the installation procedure.

 17. Configure your workstation.

     Detailed information on each configuration option is located in NET.CFG
     Options Reference

     Important For changes to take effect from your configuration, restart your
     workstation.


ΓòÉΓòÉΓòÉ 6. Configuring NetWare Client for OS/2 ΓòÉΓòÉΓòÉ

Configuring NetWare Client for OS/2

This section has information about five topics:

Configuration Overview

Using NET.CFG

NET.CFG File Format Requirements

Creating or Editing NET.CFG

Quick Reference List of NET.CFG Options


ΓòÉΓòÉΓòÉ 6.1. Configuration Overview ΓòÉΓòÉΓòÉ

Configuration Overview

After you've installed NetWare Client for OS/2 on your workstation, you must
configure it to run with your network.

Configuration options for NetWare Client for OS/2 are stored in the NET.CFG
file. When you start up your workstation, NetWare Client for OS/2 searches for
NET.CFG in the directories specified in the DPATH line in CONFIG.SYS. If
NetWare Client for OS/2 doesn't find a NET.CFG file, it starts up using the
default configuration values built into the software.

When Configuration Is Required

You must configure NetWare Client for OS/2 if

     Γûá Your workstation has more than one network board

     Γûá Your workstation has a single board, but the board is not using factory
     default settings

     Γûá Your network uses an Ethernet frame type other than Ethernet 802.2

     Γûá NetWare Client for OS/2 will share a network board with other software

 Other Situations When Configuration Might Be Useful

 Configuration may also be useful in these circumstances:

     Γûá You want to change the default packet signature security level.

     Γûá You want to turn off Packet Burst or Large Internet Packet
     transmissions.

     Γûá Your workstation will connect to a token ring network using source
     routing.

     Γûá Your workstation will use NetBIOS or Dual NetBIOS protocols.

     Γûá Your workstation will use Named Pipes protocol.

     Γûá You want your workstation to connect to a preferred Directory tree.

     Γûá You are setting up Remote Program Load (RPL) workstations.

     Γûá You want to change your default login drive.

 About Protocol Support in NetWare Client for OS/2

 NetWare Client for OS/2 provides four kinds of protocol support:

     Γûá IPX

     Γûá SPX

     Γûá Named Pipes

     Γûá NetBIOS (emulation)

 NetWare servers and client workstations use IPX as the primary protocol to
 communicate with each other. They also use SPX for some communications, such
 as communications between a workstation running NPRINTER and a NetWare print
 server. Support for IPX on the workstation is installed when you install
 NetWare Client for OS/2.

 SPX, NetBIOS, and Named Pipes protocols are provided by Novell so that NetWare
 clients and servers can also function as

 Γûá Distributed application clients and servers

 Γûá Non-NetWare network clients and servers

 Γûá Terminals connected to mainframes or minicomputers

 For example, the Lotus Notes* distributed application uses NetBIOS or SPX for
 communications; Microsoft SQL Server uses Named Pipes. LANServer networks use
 NetBIOS, and many Communications Manager connections to a gateway also use
 NetBIOS.

 Other protocols not provided with NetWare Client for OS/2 can be used for
 these purposes. For example, the TCP/IP protocol provided by Novell's LAN
 Workplace for OS/2 is commonly used for connections to UNIXΓò£ hosts. These
 other protocols are not discussed in this document.

 The figure below illustrates the components of a distributed application
 network.

 Several protocols can be installed on the same computer at the same time. All
 of these protocols can use the same network cabling, although each protocol
 might communicate on a completely separate logical network. The figure below
 shows how a NetWare network and a distributed application network share
 cabling.


ΓòÉΓòÉΓòÉ 6.2. Using NET.CFG ΓòÉΓòÉΓòÉ

Using NET.CFG

Configuration options for NetWare Client for OS/2 are stored in a NET.CFG file.
When you turn on your workstation, NetWare Client for OS/2 searches for NET.CFG
in the directories specified in the DPATH line of CONFIG.SYS. If NetWare Client
for OS/2 does not find NET.CFG, it uses a set of default configuration values
built into the software.

NET.CFG is located in the root directory of your boot drive. If you have
previously configured NetWare Client for OS/2 on a workstation, a NET.CFG file
already exists for your workstation. You can change the current configuration
by modifying and saving the existing file.

Reinstalling NetWare Client for OS/2 will not overwrite an existing NET.CFG
file; instead, the existing NET.CFG file will appear in the installation
program for you to edit.

Important If you have not configured NetWare Client for OS/2 on your
workstation before, a NET.CFG file does not exist for your workstation. You
must create this file to configure your workstation.


ΓòÉΓòÉΓòÉ 6.3. NET.CFG Format Requirements ΓòÉΓòÉΓòÉ

NET.CFG Format Requirements

The illustration below shows the NET.CFG format.

To create of modify NET.CFG, use the following rules:

Γûá Type options at the left margin of the file with no spaces before or after
them. Options are not case-sensitive.

Γûá Type one option per line.

Γûá Type settings, one per line, on the lines following the option to which they
apply.

Γûá When editing NET.CFG, use the Space bar, rather than the Tab key, to indent
these settings. The Tab key moves to the next field on the screen.

Γûá Indent settings at least one space. Settings are not case-sensitive.

Γûá Place a hard return at the end of every line in the file, including the last
line.

Warning If you don't put a hard return at the end of the last line, the line is
ignored.

Γûá Blank lines are not necessary and are ignored.

Γûá Precede comment lines with a semicolon (;).


ΓòÉΓòÉΓòÉ 6.4. Creating or Editing NET.CFG ΓòÉΓòÉΓòÉ

Creating or Editing NET.CFG

Prerequisite

NetWare Client for OS/2 is installed on your workstation.

Procedures:  To create or edit NET.CFG with the installation program

1. Go to the OS/2 desktop.

2. Choose the "Novell" icon on the desktop.

3. Choose the "Install" icon in the "Novell" window.

4. From the "Configuration" menu, select "This workstation. . ."

     The "Default Location for NET.CFG File" window appears.

 5. Enter the path of the NET.CFG file and select "Edit".

     The NET.CFG edit screen appears. If this is a new installation, there is
     not a default NET.CFG file and the "Current NET.CFG File Contents" box
     will be empty.

 6. Type the NET.CFG options you want in the "Current NET.CFG File Contents"
 box.

 A typical NET.CFG might look like

 link driver ne2000
     int 5
     port 340
     frame ethernet_802.3

 netware requester
     default login drive f
     display hard errors off
     name context "finance.novell"
     preferred tree redwood
     signature level 3

 NoteThe "default login drive" setting requires changes to the CONFIG.SYS file.
 See NET.CFG Options Reference  for more information.

 Signature level 3 is the most secure, requires Packed Burst to be enabled, and
 the server signature level needs to be set at level 1 or higher for login. See
 Improving Speed and Security for more information.

 The figure below shows a more detailed explanation of how to use the "Edit the
 NET.CFG file for this workstation" window.

 7. To save your changes to the NET.CFG file, choose "Save."

 8. To exit the installation program, double-click in the upper left corner of
 the main window.

 9. For changes to take effect from your configuration, use the OS/2 shutdown
 feature and start your workstation.

 Important Installation and configuration changes will not take effect until
 you restart your workstation.

 If you are still having problems see the Troubleshooting Section for helpful
 tips.


ΓòÉΓòÉΓòÉ 6.5. Quick Reference List of NET.CFG Options ΓòÉΓòÉΓòÉ

Quick Reference List of NET.CFG Options

The figure below lists NET.CFG options and settings and the default value for
each.


ΓòÉΓòÉΓòÉ 7. Using Network Boards and LAN Drivers ΓòÉΓòÉΓòÉ

Using Network Boards and LAN Drivers

This section provides information about five topics

 Specifying Frame Types for LAN Driver
 Matching Network Board and ODI Driver Settings
 Cautions When Changing Frame Type
 Defining Both Ethernet 802.2 and Ethernet 802.3 Frame Types
 Using More than One Network Board


ΓòÉΓòÉΓòÉ 7.1. Matching Network Board and ODI Driver Settings ΓòÉΓòÉΓòÉ

Matching Network Board and ODI Driver Settings

Important NetWare Client for OS/2 software expects each network board to use
the board's factory default settings. If you have changed the settings on your
network board, you must make corresponding changes in the OS/2 client software.
This is done through the NET.CFG.

Network boards come with factory defaults for such hardware settings as

 Γûá Direct memory access channel (DMA)
 Γûá Interrupt line (IRQ)
 Γûá Input/output port
 Γûá Memory range
 Γûá Node address

 The NetWare Client for OS/2 software, as shipped, expects each network board
 to be using the default settings. These factory defaults can usually be
 changed by moving jumpers, setting switches, or through a configuration
 utility provided by the manufacturer of the network board.

 Therefore, if you change the factory default for any of the hardware settings
 listed above, you must tell the OS/2 ODI driver the new setting.

 To do this, use the "link driver" option in NET.CFG. The "link driver" option
 allows you to configure your software to correspond to your hardware settings:

     link driver name
        dma [index] channel
        int [index] irq
        mem [index] starting_address [size]
        node address number
        port [index] starting_port [number]

 Shortcut for Microchannel and EISA LAN Drivers

 If you are using Microchannel or EISA network boards, you do not need to
 specify the hardware settings shown above. The LAN driver scans the network
 board and determines which settings are in use.

 You must tell NetWare Client for OS/2 the slot number where the network board
 is located. You can also tell NetWare Client for OS/2 to scan all slots. To
 define the network board slot, use the "Link Driver" option in NET.CFG.

     link driver name
        slot number

 Replace number with the slot number or with a question mark if you want to
 scan all slots.

 See NET.CFG Options Reference  for more information.


ΓòÉΓòÉΓòÉ 7.2. Specifying Frame Types for LAN Drivers ΓòÉΓòÉΓòÉ

Specifying Frame Types for LAN Drivers

Overview

All communications on a network consist of packets of information being sent
between computers.

There are different kinds of packets, distinguished from each other by the
order and type of the information in the packet. Each kind of packet has its
own definition, called a frame type.

For each computer to communicate by a certain frame type, each computer must be
configured to use that frame type.

A network board  in your workstation allows your workstation to communicate
with other workstations on your network and with the NetWare server.

LAN driver software serves as the link between your workstation's operating
system and the network.

By default, each LAN driver uses only one kind of frame type. However, most LAN
drivers can support other frame types if they are configured to do so through
the NET.CFG.

For example, an NE2000 LAN driver supports the following frame types: Ethernet
802.2, Ethernet 802.3, Ethernet II, and Ethernet SNAP.

The "Frame Types and LAN Drivers" table lists common frame types and the
network board drivers that support each type. This list is not comprehensive.

Link Driver Option

The Link Driver option in NET.CFG tells the Lan driver what frame types you
use. You can only specify frame types supported by that driver.

Syntax

     link driver name
        frame name

 Replace name with the name of the frame type.

 Example

 For example, to link your NE2000 LAN driver to the Ethernet 802.2 frame type,
 you would enter into your NET.CFG file.

     link driver ne2000
        frame ethernet_802.2


ΓòÉΓòÉΓòÉ 7.3. Cautions With the Default Frame Type ΓòÉΓòÉΓòÉ

Cautions With the Default Frame Type

Note:  In NetWare 2 and 3, Ethernet drivers default to the Ethernet 802.3 frame
type. In NetWare 4, they default to Ethernet 802.2 frame type.

NetWare 4 server drivers for Ethernet default to the Ethernet 802.2 frame type.
Servers and workstations must use the same frame types to communicate with each
other.

Routers must also support the same frame types or your packets will not be
routed correctly. This will disrupt communications and if your workstation does
not get a connection, it will likely fail. Some routers on your network might
not support the new Ethernet 802.2 frame type.

Important Your workstation might not connect to a network expecting the old
default of Ethernet 802.3 if you use the new default of Ethernet 802.2.


ΓòÉΓòÉΓòÉ 7.4. Defining Both Ethernet 802.2 and Ethernet 802.3 Frame Types ΓòÉΓòÉΓòÉ

Defining Both Ethernet 802.2 and Ethernet 802.3 Frame Types

You can define both Ethernet 802.2 and Ethernet 802.3 on your network to
eliminate conflicts due to default frame type settings.

For your workstation, define frame types in NET.CFG. Include a line similar to
the following, replacing ne2000 with the name of your ODI driver:

     link driver ne2000
        frame ethernet_802.3
        frame ethernet_802.2

 The first frame type defined is the only one used for the initial "Get Nearest
 Server" request. Therefore, if you have servers using only one frame type,
 such as Ethernet 802.3, put that frame type first. That way your workstation
 can make a default connection to those servers.

 See NET.CFG Options Reference for more information about the link driver
 option.


ΓòÉΓòÉΓòÉ 7.5. Using More than One Network Board ΓòÉΓòÉΓòÉ

Using More than One Network Board

Note:  In most cases NetWare Client for OS/2 can share a network board with
other communications packages so you do not need to purchase two network
boards.

This section describes

Γûá Reasons for having more than one network board

Γûá Setting up two network boards

Γûá Choosing a primary network board

Reasons for Having More Than One Network Board

When using NetWare Client for OS/2, there are two conditions where you might
benefit from having more than one network board in your computer:

Γûá When each network board supports a different communications software package

Γûá When each network board is connected to a physically separate network

If you have two network boards, be aware of the configuration issues in the
following sections.

Additional network boards (those after the second defined network board) are
ignored.

Different Communications Packages

You might want to use two or more network boards when each board is supported
by its own communications software package.

For instance, you might want to have Communications Manager use one network
board and NetWare Client for OS/2 use another. Or you might want NetWare for
OS/2 to use one network board and the NetWare Client for OS/2 to use another.

In these cases, each package provides the driver for its own board. The setup
for NetWare Client for OS/2 is the same as if only one network board existed.
There are no additional steps to set up the second network board under NetWare,
since that network board is controlled by the other communications package. It
may need to be configured under the other communications package.

Note:  In most cases, NetWare Client for OS/2 can share a network board with
other communication packages, so you do not need to purchase two network
boards.

Physically Separate Networks

You might want to use two network boards with each board being connected to its
own network. This makes it possible for a custom application to access both
networks at one time. However, a workstation with only NetWare Client for OS/2
cannot serve as a router between the two networks. This means that, although
both networks are connected to the same physical machine, there is no
communication between the two networks. (The OS/2 workstation can become a
router using NetWare for OS/2).

If your two networks are connected through another machine serving as a router,
your second network board may serve as a backup route if the connection to your
first board fails. Again, your OS/2 workstation is not routing (unless you are
using NetWare for OS/2).

Using The Second Network Board as a Backup

When the workstation boots, the IPX protocol binds to all network boards that
have OS/2 ODI drivers loaded. Whenever NetWare Client for OS/2 needs to find a
new destination on the network, it queries the network for possible routes to
that destination.

Important NetWare Client for OS/2 sends out a destination query only on the
primary network board. It never queries the secondary (or other) board for a
route. If NetWare Client for OS/2 doesn't find the destination using the
primary network board, you see a connection error, even if the destination
could be found using the second network board. (However, the network on the
second network board can be queried using IPX calls from a custom program).

Once NetWare Client for OS/2 finds a destination using the primary network
board, it stores the route to that destination in a router table and makes a
connection.

After a connection is made, NetWare Client for OS/2 checks all networks
connected to that destination for other possible routes from your OS/2
workstation to the destination.

If it finds a secondary route, NetWare Client for OS/2 rebuilds the router
tables and stores that route. If the primary connection fails, NetWare Client
for OS/2 will use the secondary route to continue transmissions to that
destination.

If NetWare Client for OS/2 is using a route through the second network board,
the primary connection can be broken without causing the secondary connection
to fail.

However, the secondary network board never becomes the primary board, even if
the primary board fails. This means that if NetWare Client for OS/2 needs to
find a new destination while the primary connection is down, it can't query for
the destination, since queries are only sent on the primary board.

Important To allow NetWare Client for OS/2 to find new destinations, restore
the primary connection.

Setting Up Two Network Boards

If you have two network boards in your computer, you may need to

Γûá Define hardware settings and frame type for each network board

Γûá Load a driver for each board

Γûá Choose a primary network board

Defining Hardware Settings and Frame Type for Each Network Board

If you have more than one network board, you will need to load a separate
driver and specify a "Link Driver" section for each network board.

For example, if you have an NE2000 board (the primary board) and a token ring
network board, you might include these in NET.CFG.

     link driver ne2000
        frame ethernet_802.3
        frame ethernet_802.2
        int 5
        port 360

     link driver token
        frame token-ring
        frame token-ring_snap
        int 3
        port A20
        mem CC00

 Loading the ODI Driver for an Additional Network Board

 NetWare Client for OS/2 installation program allows you to specify an ODI
 driver. That driver is then autoloaded in CONFIG.SYS, but you might need to
 load an additional ODI driver manually in the CONFIG.SYS file if

 Γûá You have two network boards, and

 Γûá Those network boards use different ODI drivers.

 Important If the network boards use the same ODI driver (for example, two
 NE2000 boards), load the driver once when you install NetWare Client for OS/2.

 Prerequisites

 Checklist  Install NetWare Client for OS/2 with one of the ODI drivers.

  Check to see if the second network board is installed and free from hardware
 conflicts.

 Procedure

 1. Using a text editor, open CONFIG.SYS.

     For example, to use the OS/2 System Editor at the OS/2 command line, type

     E C:\CONFIG.SYS <Enter>

     CONFIG.SYS is in the root of your boot drive. (In this example, drive C:
     is the boot drive.)

 2. In NetWare Client for OS/2 lines, find the line loading the first ODI
 driver.

 3. Decide which driver you want IPX to recognize as primary.

     The driver for the primary network board is the only driver IPX uses to
     query the network for a route. The driver for the secondary network board
     is never queried.

 4. Type a new line to load an additional driver.

     To load a driver as primary, type the line above the existing driver line.
     To load a driver as secondary, type the line below the existing line.

     The first driver loaded in CONFIG.SYS is the primary driver.

     Type the path to the driver in the line. If you use a Novell-supplied
     driver, the driver is located in the directory where you installed the
     NetWare Client for OS/2 files, usually in C:\NETWARE.

     For example, to load an NE2000 driver from the default location, type

     DEVICE=C:\NETWARE\NE2000.SYS

 Note:  If you have two network boards using the same driver name (such as two
 NE2000 boards), do not load the driver twice.

 5. Save and exit the CONFIG.SYS file.

 6. Edit NET.CFG to reflect the changes.

 7. Use the OS/2 "shutdown" feature to reboot your machine in order to load the
 additional drivers.

 Choosing a Primary Network Board

 The network board whose driver loads first in CONFIG.SYS is the primary
 network board. You can change which network board is primary by

 Γûá Reordering drivers in CONFIG.SYS.

 Γûá Using a NET.CFG option to bind IPX to a different driver.

 To change which network board IPX views as primary, use the "Protocol Stack
 IPX" option in NET.CFG.

     protocol stack ipx
        bind drivername

 Replace drivername with the name of the driver that controls the network
 board, and indent the "bind" setting. For example, to set a token ring board
 as primary, type

     protocol stack ipx
        bind token

 2.Switching the Network Board in Use on Unconnected Networks

 If you have two network boards and each is connected to a physically separate
 network, you might want to

     Γûá Change which board is primary in NET.CFG and reboot when you want to
     access the other network.

     Γûá Get a network switch box that allows you to change between physically
     separate networks.

     Γûá Connect the networks with a router.

     Specifying Primary with Two Network Boards of the Same Type

     If you have two network boards using the same type of ODI driver (such as
     two NE2000 boards), do not load the same driver twice in the CONFIG.SYS
     file and do not specify a "Protocol Stack IPX" option.

     Instead, use the "link driver" option in NET.CFG to specify that the
     driver is used twice. Do this by placing two "link driver" sections in
     NET.CFG, each one specifying the driver name and hardware settings used by
     that network board.

     The hardware settings for at least one of the network boards must be
     specified, since you cannot have two network boards of the same type both
     using the default hardware settings.

     For example, if you have two NE2000 network boards, you might include the
     following lines in the NET.CFG file:

     link driver ne2000
        frame ethernet_802.2
        frame ethernet_802.3
        int 5
        port 360

     link driver ne2000
        frame ethernet_802.2
        frame ethernet_802.3
        int 4
        port 320

     Putting two occurrences of "link driver ne2000" loads the NE2000 driver
     twice.

     If you do not specify two "Link Driver" sections, a driver will not be
     loaded for the second board, and the second network board is ignored.

     Important The network board whose line comes first in the NET.CFG file is
     the one IPX uses as primary.

     Shortcut for Multiple EISA and Microchannel Boards

     If you are using two EISA or Microchannel boards that use the same driver
     (such as NE3200 or 3C523), you still must specify a "Link Driver" section
     for each board.

     However, instead of specifying the hardware settings used on the network
     board, you can specify the "slot" setting. The "slot" setting tells the
     ODI driver which slot a network board is in. The driver then scans the
     board and automatically determines what hardware settings are in use.

     For example, for two NE3200 boards, type

     link driver ne3200
        frame ethernet_802.3
        frame ethernet_802.2
        slot 2

     link driver ne3200
        frame ethernet_802.3
        frame ethernet_802.2
        slot 1

     In this example, the network board in slot 2 becomes the primary network
     board because the driver for it was loaded first.

     To change which network board is primary, reorder the "Link Driver"
     sections. For example, to set the network board in slot 1 as primary, type

     link driver ne3200
        frame ethernet_802.3
        frame ethernet_802.2
        slot 1

     link driver ne3200
        frame ethernet_802.3
        frame ethernet_802.2
        slot 2


ΓòÉΓòÉΓòÉ 8. Logging In to Your Network ΓòÉΓòÉΓòÉ

Logging In to Your Network

The following topics are available:

Setting Up Workstations to Log In

Understanding Logging In to NetWare Directory Services (NDS)

Logging In from the OS/2 Command Line

Logging In to NetWare 2 and 3 Bindery Servers with NDS Utilities

Modifying NET.CFG To Log In to NetWare 2 or 3

Modifying NET.CFG TO Log In to NetWare 4

Network Login Window


ΓòÉΓòÉΓòÉ 8.1. Setting Up Workstations to Log In ΓòÉΓòÉΓòÉ

Setting Up Workstations to Log In

OS/2 supports a variety of operating system platforms referred to as
"sessions." The following headings will direct you to the kind of login that
works best with the platform you use.

Proper workstation setup can make logging in to a bindery and NetWare Directory
Services network virtually transparent. This chapter assumes that the following
tasks are completed:

Checklist  NetWare Client for OS/2 is installed and running on your
workstation

 Your workstation NET.CFG file has been modified for login

 A User object or user account is created for each user

 A home directory is created for each user

With the necessary modifications made to your NET.CFG file, you need only your
username and password to log in.


ΓòÉΓòÉΓòÉ 8.2. Understanding Logging In to NetWare Directory Services (NDS) ΓòÉΓòÉΓòÉ

Understanding Logging In to NetWare Directory Services (NDS)

NetWare Directory Services (NDS), used in NetWare 4, makes logging in
convenient because you log in to the network rather than log in to a server.
User information resides in a global database. Each "User Object" is assigned a
position, or "context" within the database that informs the network where your
workstation is in relationship to the network. This context is referred to as
your "name context."

When you log in, the LOGIN utility must know your context, or where your
particular User object is located. The User object's context forms its complete
name. The path from the object to the root of the tree forms the object's
complete name, which is unique among other object's names.

Your User object's complete name is a bottom-up traversal of the tree, from the
object up to the root.

Using Your Complete Name for Logging In

When you use a complete name of a User object, specify the common name first,
followed by a period (.). Then specify the container object, also followed by a
period, and so on up through the Organization object name (and the Country
object name, if used).

So, depending on the way your network is defined, your User object's complete
name could be represented by:

     Common name.Organizational Unit name.Organization name.Country name

 Specifying the Name Type of an Object

 At times, such as when you move from one Container object to another, you must
 include the name type of the object when typing out the complete name of the
 object. A name type distinguishes the class of object you are referring to,
 such as a User object or an Organizational Unit object.

 For example, you could express

 ESAYERS.SALES PV.SALES.NOVELL US

 as:

 CN=ESAYERS.OU=SALES PV.OU=SALES.O=NOVELL US

 where CN is the common name of the User object, OU is the Organizational Unit
 name, and O is the Organization name.

 If you refer to an object that is in the same Container object as your User
 object, refer to that object only by its common name instead of its complete
 name.

 Important You must always include the name type of the object (CN or OU or O)
 in the complete name when you include the Country object in your Directory
 tree, even when referring to objects located in the same Container object.

 Changing Your Context

 You may need to change your context to simplify your login or your reference
 to other objects in your Directory tree. Two ways to change your context are:

 Γûá Using the CX.EXE, included with NetWare Client for OS/2.

 Γûá Using the "name context" command in NET.CFG.


ΓòÉΓòÉΓòÉ 8.3. Logging In from the OS/2 Command Line ΓòÉΓòÉΓòÉ

Logging In from the OS/2 Command Line

Important The default login drive is drive L:, unless it has been changed in
your NET.CFG.

NetWare Client for OS/2 maps drive L: as the default login drive, mapped to
SYS:LOGIN. However, you should log in from your NetWare workstation directory
(default C:\NETWARE). LOGIN connects your workstation to the network.

Logging In to NetWare Directory Services

Procedure

1. Open an OS/2 Full Screen or Window.

     A prompt similar to the following appears:

     [C:/]

 2. Log in using one of the following ways:

     2a. To log in using your username only, type

     login username <Enter>

     For example, type

     login esayers <Enter>

     2b. To log in to a specific server, type

     login servername\username <Enter>

     For example, type

     login tsmkt\esayers <Enter>

 3. If required, type your password.


ΓòÉΓòÉΓòÉ 8.4. Logging In to NetWare 2 and 3 Bindery Servers Using NDS Utilities ΓòÉΓòÉΓòÉ

Logging In to NetWare 2 and 3 Bindery Servers Using NDS Utilities

Important The default login drive is drive L:, unless it has been changed in
your NET.CFG file.

Procedure

1. Type

     login server/username /b <Enter>

     Replace "server" with the name of the bindery server. Replace "username"
     with your username. For example, type

     F:\login tsmkt/esayers /b <Enter>

 2. If required, type your password.


ΓòÉΓòÉΓòÉ 8.5. Modifying NET.CFG To Log In To NetWare 2 or 3 ΓòÉΓòÉΓòÉ

Modifying NET.CFG To Log In To NetWare 2 or 3

When logging in to NetWare 2 or 3, you attach to a server. Following, you make
additional attachments to other servers you have a user account on.

Using the Preferred Server Setting

To direct NetWare Client for OS/2 to the server your user information is saved
on, use the preferred server setting in the NET.CFG file. For networks with
multiple servers, this setting is very useful to speed up logging in to the
network. This setting also allow you to log in with only your username.

Adding the Preferred Server Setting to NET.CFG for OS/2

Procedure

1. Using a text editor, open your NET.CFG.

     Your workstation's NET.CFG file was copied to the target directory for
     OS/2 files specified during the NetWare Client for OS/2 installation.

 2. Under the "NetWare Requester" option, type

     preferred server <servername>

     For example, type

     preferred server mktsales

 Example of the NetWare Requester Line for OS/2

     Netware Requester
        Preferred server mktsales


ΓòÉΓòÉΓòÉ 8.6. Modifying NET.CFG To Log In To NetWare 4 ΓòÉΓòÉΓòÉ

Modifying NET.CFG To Log In To NetWare 4

When logging in to NetWare 4, you don't attach to individual servers (as with
previous versions of NetWare), but you log in to the entire network.

With your complete name (CN), you can simplify the login process by adding
information to your workstation's NET.CFG file. You add lines to the NetWare
Requester option.

If you add lines for the following settings, you don't need to type your
complete name each time you log in. The settings are:

Γûá Name Context

Γûá Preferred Tree

You must know your context before making these modifications. Without knowing
the context, you can't add entries for the settings.

Using the Name Context Setting

To inform NetWare Client for OS/2 of your name context, use the "name context"
setting in NET.CFG. LOGIN can then locate your User object and connect you to
the network.

If you are using NetWare 4, add this setting to NET.CFG. The setting is as
follows:

 netware requester
     Name Context "context"

 Using the Preferred Tree Setting

 To direct NetWare Client for OS/2 to the Directory tree where your name
 context is set, use the "preferred tree" setting in NET.CFG. LOGIN can then
 search only the preferred Directory tree.

 If you are using NetWare 4 on a network with multiple Directory trees, add
 this setting to your NET.CFG file. The setting is as follows:

 netware requester
     preferred tree treename

 The default is set to the root, so if duplicate usernames exist within
 separate Directory trees, the "preferred tree" setting avoids confusion.

 Note Don't use both "preferred server" and "preferred tree" simultaneously.
 The second setting overrides the first.


ΓòÉΓòÉΓòÉ 8.7. Network Login Window ΓòÉΓòÉΓòÉ

Network Login Window

When booting OS/2 2.1, a pop-up network login window sometimes displays,
because OS/2 can restart PROGRAMS, TASKLIST, FOLDERS, and CONNECTIONS
automatically by using the SET AUTOSTART variable in CONFIG.SYS.

For example, if the following line is in CONFIG.SYS,

SET AUTOSTART=PROGRAMS, TASKLIST, FOLDERS, CONNECTIONS

then the pop-up login window displays.

In a NetWare environment, it is best not to include the SET
AUTOSTART=CONNECTIONS line in CONFIG.SYS. The recommended syntax is

SET AUTOSTART=PROGRAMS, TASKLIST, FOLDERS

Use the OS/2 version of LOGIN or NetWare Tools to log in because these
utilities allow you to automatically set up your NetWare environment (map
drives and capture ports) and the pop-up login window does not.

The OS/2 version of LOGIN will run OS/2 login scripts (system and/or user login
scripts) and NetWare Tools allows you to create and load file settings that
function similar to login scripts.


ΓòÉΓòÉΓòÉ 9. Using Virtual DOS and Windows ΓòÉΓòÉΓòÉ

Using Virtual DOS and Windows

Overview

From a virtual DOS or MS Windows session, you can have three kinds of NetWare
support:

Global logins

     All DOS, MS Windows, and OS/2 sessions set up for global login support
     share a single login to a NetWare server. Drives that are mapped in one
     session apply to the other sessions. A port captured in one session is
     also captured in other sessions. This is useful in environments where the
     number of connections is carefully monitored.

 Private logins

     All DOS and MS Windows sessions set up for private login support have
     their own logins to a NetWare server. Drive mappings and port captures
     from one session do not apply to the other sessions. This is useful in
     environments where users need more than one connection to a server and
     where users need logins from DOS or MS Windows sessions to be separate
     from logins from OS/2 sessions.

 No logins

     Sessions with network support disabled have IPX/SPX support, but no
     NetWare login support.

 Set up NetWare support for virtual DOS and MS Windows in two ways:

 1. Set a default type of support (global, private, none) that applies to all
 existing DOS and MS Windows icons, as well as any new icons that are created.

     If you choose this default in NetWare Client for OS/2 Installation
     program, it is automatically loaded in the CONFIG.SYS file. To change the
     default support

          Γûá Run the NetWare Client for OS/2 Installation program.

          Γûá Under the "Installation" menu, choose "Requester on workstation..."

          Γûá Select the appropriate target directory and choose "OK."

          Γûá Under the "Requester Installation" window, select "Only Edit
          CONFIG.SYS..." Choose "OK."

          Γûá Under "Choose ODI LAN driver," choose "Continue" unless changes
          have been made in your LAN driver configuration.

          Γûá Under "Choose NetWare Support of DOS and Windows Applications",
          select the desired default support. Choose "Continue."

          Γûá Continue installation.

          2. Customize the type of support for each DOS and MS Windows icon on
          your desktop.

          All sessions started from the customized icon have the type of
          support you specify. For instructions on customizing NetWare support
          per icon, see the sections that follow.

 To set up icons with different kinds of network support, label the icons for
 those sessions something that indicates the type of support. For example, you
 might want to create Global DOS Full Screen and Private DOS Full Screen icons.

 Topics
 Information for All Types of Sessions
 Logging In from an OS/2 Virtual DOS Session
 Customizing Icons For Global Support
 Setting Up Drive Mappings in Global Sessions
 Customizing Icons For Private Support
 Special Instructions for Win-OS2 Icons
 Special Instructions for DOS_STARTUP_DRIVE Sessions
 Disabling Network Support in All Virtual Sessions
 Setting Up Named Pipes for Virtual DOS and MS Windows
 Setting Up NetBIOS for Virtual DOS and MS Windows


ΓòÉΓòÉΓòÉ 9.1. Information for All Types of Sessions ΓòÉΓòÉΓòÉ

Information for All Types of Sessions

NetWare 3 and 4 Support

From a virtual DOS or MS Windows session, you can access NetWare 3
(bindery-based) networks. On these networks, you can receive full NetWare
support, just as if you were using an actual DOS or MS Windows workstation. You
can also receive support for just the IPX, SPX, Named Pipes and NetBIOS
protocols.

Note You cannot access NetWare 4 networks from virtual DOS and MS Windows
sessions unless those networks support bindery emulation. If a NetWare 4
network supports bindery emulation, your DOS or MS Windows session will be seen
as a bindery-based client.

Accessing the Correct Version of DOS

For all virtual sessions you start, the COMSPEC variable must point to the
correct version of DOS. If you use the version of DOS included with OS/2, set
the COMSPEC variable to the following

     SET COMSPEC=drive:\OS2\MDOS\COMMAND.COM

 You can set the COMSPEC variable at the command line, in a login script, or
 through "DOS Setting" from the OS/2 desktop.

 Replace drive: with the letter of your boot drive. If you are running another
 version of DOS, the COMSPEC variable should point to the location of the
 COMMAND.COM file for that version.

 NetWare login scripts often contain a statement assigning COMSPEC to a network
 drive, so be sure to check-and if necessary, reset-the COMSPEC variable in
 your login script.

 Login Issues

 The How to Edit Login Scripts For Each Type of Session table shows which login
 scripts are executed from which type of session and how to edit those login
 scripts.

 Logout Issues

 When you log out from a local drive in a DOS session, the drive for your login
 directory is the last drive (set with DOS_LAST_DRIVE in DOS Settings) plus
 one. For example, if your last DOS drive is C:, the drive you see after
 logging out is drive D:.

 If you log out from a network drive, the drive remains the same.


ΓòÉΓòÉΓòÉ 9.2. Logging In from an OS/2 Virtual DOS Session ΓòÉΓòÉΓòÉ

Logging In from an OS/2 Virtual DOS Session

Logging in from an OS/2 virtual DOS session is the same as logging in from a
DOS prompt.

NoteYou cannot log in to a NetWare 4 network from a virtual DOS session unless
the network supports bindery emulation. If a NetWare 4 network supports bindery
emulation, your DOS session is seen as a bindery-based workstation.

Procedure  If you added NETX.EXE to your AUTOEXEC.BAT file during the NetWare
Client for OS/2 installation, skip to Step 2.

     1. Load the NetWare shell (NETX.EXE) for both global and private sessions.
     Type

     NETX.EXE

 NoteThe OS/2 virtual DOS environment does not support NetWare Directory
 Services (NDS) and NetWare 4 VLMs. This means that you can log in to a NetWare
 3 server or a NetWare 4 server through bindery emulation. You must first load
 NETX.EXE before logging in.

     2. Open a virtual DOS Full Screen or DOS Window.

     A prompt similar to the following appears:

     [C:/]

     3. Change to the first network drive.

     3a. For global sessions, type

          L: <Enter>

          NetWare Client for OS/2 maps drive L: to the first network drive
          default unles you've changed the parameter in NET.CFG.

     3b. for private sessions, use the drive that is the next letter away from
     the DOS LASTDRIVE, or your last physical drive.

          For example, if you indicated that drive D: is your last DOS drive,
          or last physical drive, you could map drive E: to a network drive.
          Drive E: is the next letter away from drive D:, your last physical
          drive.

 4. Type

 login server/username <Enter>

 Replace server with the name of the bindery server. Replace username with your
 username. For example, type

 F:\login tsmkt/esayers  <Enter>

 5. If required, type your password.

 Logging In from an OS/2 Virtual DOS Boot Session (VMBOOT)

 Logging in from an OS/2 VM Boot environment is the same as logging in from a
 DOS prompt.

 Important You must first open a VMBOOT full screen or window before initiating
 login procedures from the DOS prompt in OS/2.


ΓòÉΓòÉΓòÉ 9.3. Customizing Icons for Global Support ΓòÉΓòÉΓòÉ

Customizing Icons for Global Support

Prerequisites

Checklist

 See Information for All Types of Sessions

 Make sure network support for virtual sessions is enabled. If not, enable it
by running the NetWare Client for OS/2 Installation program. Virtual session
support is enabled by default.

Procedure To set up global NetWare support for an icon, do the following:

1. Open the "DOS Settings" notebook for the DOS or MS Windows icon on your
desktop.

     For information on opening DOS Settings, see "DOS Settings" in the OS/2
     online "Master Help Index."

 2. In the "DOS Settings" Notebook, choose the "Session" tab.

 3. On the "Session" screen, choose "DOS Settings . . ."

 4. (Optional) Enable the NetWare CAPTURE feature for the session.

     4a. Select "DOS_DEVICE" on the "DOS Settings" screen

     4b. Type the following line in the "Value" field:

     drive:\OS2\MDOS\LPTDD.SYS

     Replace drive with the drive letter of your boot drive. Add this line only
     if you want to use the CAPTURE command from the virtual session.

     NoteIf you want this device driver to be loaded for every virtual session
     you open, you can load it in the OS/2 CONFIG.SYS file instead of in the
     "DOS Settings" notebook. (See the OS/2 online "Master Help Index" for
     information on loading DOS device drivers.)

 5. Specify that all drives are available to NetWare.

     5a. Select "DOS_LASTDRIVE."

     5b. Type the drive letter for your last physical drive in the value field.

          For example, if the last physical drive on you client workstation is
          drive D:, type D in the value field.

 Important The last physical drive for all global sessions will be the last
 physical drive indicated in the "DOS_LASTDRIVE" setting.

 6. Specify how many files the session can open simultaneously.

     6a. Select "DOS_FILES."

     6b. Type 214.

     7. Choose Global NetWare support.

     7a. Select "NETWARE_RESOURCES."

     7b. Type GLOBAL in the "Value" field.

     You can also choose "GLOBAL" from the drop-down list. Every session you
     start from this icon will have global support.

 8. Enable virtual IPX for this session.

     8a. Select "VIPX_ENABLED."

     8b. Select "On."

 9. Save and exit "DOS Settings."

 10. Load NETX.EXE in each session where you want to log in to the network.

 To load NETX.EXE automatically for every session you start from a particular
 icon, use Optional Parameters on the DOS Settings notebook for that icon.

 In the Optional Parameters box, type /K followed by a space, the directory
 path, and the NETX.EXE filename. The file will then execute at the start of
 every session opened from that icon.

 For example, to load NETX.EXE from the default location, type

 /K C:\NETWARE\NETX.EXE

 For more about optional parameters, see "parameters, starting programs with"
 in the OS/2 online Master Help Index.

 To load NETX.EXE automatically for all DOS and MS Windows sessions, put the
 following command in an AUTOEXEC.BAT file at the root of your boot drive:

 drive:\path\NETX

 Replace drive and path with the location of your NETX.EXE file. By default,
 NETX is installed in \NETWARE with the NetWare Client for OS/2 files.

 NoteIf you want IPX/SPX-only support, don't load NETX. If you don't load NETX,
 you can't log in to a NetWare network, but DOS and MS Windows applications can
 use the IPX protocol.


ΓòÉΓòÉΓòÉ 9.4. Setting Up Drive Mappings in Global Sessions ΓòÉΓòÉΓòÉ

Setting Up Drive Mappings in Global Sessions

Drive mappings in DOS differ from drive mappings in OS/2. In OS/2, all mapped
drives function like root drives, so drives mapped in OS/2 sessions show up as
root drives in global DOS sessions. Root drives mapped in global DOS sessions
show up as root drives in OS/2 sessions.

Search drive mappings are not used in OS/2. Therefore, search drives mapped in
global DOS sessions are ignored in OS/2 sessions. Also, search drives mapped in
one global DOS session do not apply to other global DOS sessions. To eliminate
confusion, avoid using search drives in a global environment. Instead, set up
your environment as outlined in the following procedures.

Procedure

1. Decide which drives you want mapped in your global environment. Decide which
of those drives need to be included in a search path.

2. Edit your NetWare 4 login script (used in OS/2 sessions) and include MAP
statements for all NetWare drives.

3. Edit your NetWare 3 DOS login script and include MAP ROOT statements for all
NetWare drives.

To edit your NetWare 3 DOS login script, use a text editor to edit the
SYS:MAIL\userID\LOGIN file or use a NetWare 3 utility such as SYSCON.

Use MAP ROOT rather than MAP for consistency between DOS and OS/2 sessions. For
easiest maintenance, both login scripts should contain identical map
statements.

4. Edit your OS/2 CONFIG.SYS file and include the drive letters you want to be
searchable in your PATH statement.

This path is where OS/2 searches for .EXE, .CMD, and .COM files. For example,
to include drive H: in the search path, add the following to your path:

H:\;

If needed, you can also include drive letters in the data path statement
(DPATH). DPATH is where OS/2 searches for non-executable, non-.DLL files.

5. Create a DOS.BAT file which includes a path to the same drives you included
in CONFIG.SYS.

This path is where DOS searches for files. For example, to include drive H: in
the search path, type the following line in your .BAT file:

SET PATH=%PATH%;h:\;

Note that the "%PATH%" appends whatever you type to the existing PATH
statement.

You can't include DPATH statements in the DOS.BAT file. PATH statements are
limited to 123 characters, so try to map drives to the exact directories you
need and minimize the number of subdirectories you specify.

6. Run the .BAT file each time you open a DOS global session.

You can use "Optional Parameters" on the "Settings" notebook. In the "Optional
Parameters" box, type /K followed by a space and the name of the batch (.BAT)
file. The file is then executed at the start of every session opened from that
icon.

For more information about PATH, DPATH, Settings, or Parameters, see the OS/2
online "Master Help Index."


ΓòÉΓòÉΓòÉ 9.5. Customizing Icons For Private Support ΓòÉΓòÉΓòÉ

Customizing Icons For Private Support

Prerequisites

Checklist

 See Information for All Types of Sessions.

 Make sure network support for virtual sessions is enabled. If not, enable it
by running the NetWare Client for OS/2 Installation program. Virtual session
support is enabled by default.

Procedures

To set up private NetWare support for an icon, do the following:

1. Open the "DOS Settings" notebook for the DOS or MS Windows icon on your
desktop.

For more information on opening DOS Settings, see "DOS Settings" in the OS/2
online "Master Help Index."

2. In the "DOS Settings" notebook, choose "Session".

3. On the "Session" screen, choose "DOS Settings . . ."

4. (Optional) Enable CAPTURE for the session.

     4a. Select "DOS_DEVICE" on the "DOS Settings" screen

     4b. Type the following line in the "Value" field:

     drive:\OS2\MDOS\LPTDD.SYS

     Replace drive with the drive letter of your boot drive. Add this line only
     if you want to use CAPTURE from the virtual session.

     NoteIf you want this device driver to be loaded for every virtual session
     you open, add it to the OS/2 CONFIG.SYS file instead of the "DOS Settings"
     notebook. (See the OS/2 online "Master Help Index" for information on
     loading DOS device drivers.)

 5. Specify how many files the session can open simultaneously.

     5a. Select "DOS_FILES."

     5b. Type 214 in the "Value" field.

 6. Specify which drives are available to NetWare.

     6a. Select "DOS_LASTDRIVE."

     6b. Type a drive letter other than Z in the "Value" field.

     All drives after this letter are available to the private NetWare
     connection in this session. All drives up to this letter are on your local
     hard drive or available for use in global sessions.

 7. Choose Private NetWare support.

     7a. Select "NETWARE_RESOURCES."

     7b. Type PRIVATE in the "Value" field.

     You can also choose "Private" from the drop-down list. Every session you
     start from this icon will its own NetWare login.

 8. Enable virtual IPX for this session.

     8a.Select "VIPX_ENABLED."

     8b. Select "On."

 9. Save and exit "DOS Settings."

 10. Load NETX.EXE in each session where you want to log in to the network.

 To autoload NETX.EXE for every session you start from a particular icon, use
 "Optional Parameters" on the "DOS Settings" notebook for that icon.

 In the "Optional Parameters" type /K followed by a space, the directory path,
 and the NETX.EXE filename. The file is then executed at the start of every
 session opened from that icon. For example, to load NETX.EXE from the default
 location, type the following:

 /K C:\NETWARE\NETX.EXE

 For more information about optional parameters, see "parameters, starting
 programs with" in OS/2 online Master Help Index.

 To autoload NETX.EXE for all DOS and MS Windows sessions, put the following
 command in an AUTOEXEC.BAT file at the root of your boot drive:

 drive:\path\NETX.EXE

 Replace drive and path with the location of your NETX.EXE file. By default,
 NETX.EXE is installed in \NETWARE with the NetWare Client for OS/2 files.

 NoteIf you want IPX/SPX-only support, don't load NETX.EXE. If you don't load
 NETX.EXE, you can't log in to a NetWare network, but DOS and MS Windows
 applications can use the IPX protocol.


ΓòÉΓòÉΓòÉ 9.6. Special Instructions for Win-OS2 Icons ΓòÉΓòÉΓòÉ

Special Instructions for Win-OS2 Icons

NoteNetWare and NetWare Client for OS/2 provide name space support. See
"Concepts" for more about name space.

These instructions apply to the MS Windows 3.x support that was shipped with
OS/2 v2.x.

Prerequisites

Checklist  Read Information for All Types of Sessions.

 Complete Customizing Icons for Global Support or Customizing Icons for
Private Support

Procedures You need several additional files for Win-OS2 NetWare support:

 NWIPXSPX.DLL
 NETWARE.DRV
 TBMI2.COM
 NWPOPUP.EXE
 NETWARE.HLP
 NWNETAPI.DLL
 NETAPI.DLL

 By default, these files are copied to the \OS2\MDOS\WINOS2\SYSTEM directory on
 your boot drive when you install NetWare Client for OS/2. If you are using
 OS/2 for Windows, these files are copied to the WINDOWS directory.

 Important The TBMI2.COM must be loaded before you run any MS Windows programs
 that make IPX or SPX calls. If you did not install TBMI2.COM during the
 NetWare Client for OS/2 installation, we recommend that you load it before you
 run any MS Windows programs.

 TBMI2.COM does not load automatically. To autoload TBMI2.COM for all sessions
 started from a single icon:

 Procedure 1. Make and use a copy of a DOS icon.

 2. Create a batch file (.BAT extension) with the following lines:

     drive:\OS2\MDOS\WINOS2\SYSTEM\TBMI2.COM
     WINOS2.COM
     EXIT

     Replace drive with the letter of your boot drive.

 3. Save the batch file in the following directory:

     \OS2\MDOS\WINOS2\SYSTEM

 4. Open the "Settings" for the icon.

 5. Choose "Program".

 6. In the "Optional Parameters" field, type the following

     /K drive:\OS2\MDOS\WINOS2\batchfile.bat

     Replace drive with the letter of your boot drive. Replace batchfile with
     the name of your batch file.

 7. Choose "Session".

 8. Make sure "DOS Full Screen" is selected.

 Each time you choose this icon, TBMI2 is loaded and Win-OS2 is started.

 For more information about optional parameters, see "parameters, starting
 programs with" in OS/2's online Master Help Index.

 To autoload TBMI2.COM for all DOS and MS Windows sessions, put the following
 command in an AUTOEXEC.BAT file in the root of your boot drive:

 drive:\OS2\MDOS\WINOS2\SYSTEM\TBMI2.COM

 Replace drive with the letter of your boot drive.


ΓòÉΓòÉΓòÉ 9.7. Special Instructions for DOS_STARTUP_DRIVE Sessions ΓòÉΓòÉΓòÉ

Special Instructions for DOS_STARTUP_DRIVE Sessions

If you want to boot a version of DOS other than the one shipped with OS/2,
refer to the OS/2 online Master Help Index, which explains more about the
DOS_STARTUP_DRIVE feature.

The following sections explain how to set up DOS_STARTUP_DRIVE sessions
globally or privately.

Setting up Global DOS_STARTUP_DRIVE Sessions

Prerequisites

 See Information for All Types of Sessions

 Set up your session to boot from another version of DOS. This involves
several tasks, such as creating a boot image file, and setting
DOS_STARTUP_DRIVE. You may want to set up another partition on your hard drive
(although not necessary), as well as do certain other tasks using the VMDISK
utilitly. See the OS/2 online "Master Help Index."

 Make sure network support for virtual sessions is enabled. If not, enable it
by running the NetWare Client for OS/2 installation program. Virtual session
support is enabled by default.

 Set up your session for global NetWare support by following the instructions
in Customizing Icons for Global Support or Customizing Icons for Private
Support and Setting Up Drive Mappings in Global Sessions.

Procedures:

1. Add the following lines to the CONFIG.SYS file on the DOS diskette or
partition you boot from:

 device=drive:\os2\mdos\fsfilter.sys
 device=drive:path\dosvipx.sys
 lastdrive=last physcial drive

     Replace drive and path with the drive and path names where the NetWare
     Client for OS/2 files are located.

     Type the lastdrive line only if you want the last global drive to be
     something different than the last drive in use by OS/2 at the time you
     start the virtual session.

 2. Load NETX.EXE

 Setting Up Private DOS_STARTUP_DRIVE Sessions

 Prerequisites

  See Information for All Types of Sessions

  Set up your session to boot from another version of DOS. This involves
 several tasks such as creating a boot image file, and setting
 DOS_STARTUP_DRIVE. You may want to set up another partition on your hard drive
 (although not necessary), as well as do certain other tasks using the VMDISK
 utilitly. See the OS/2 online "Master Help Index."

  Make sure network support for virtual sessions is enabled. If not, enable it
 by running the NetWare Client for OS/2 installation program.

  Set up your session for private NetWare support by following the
 instructions in Customizing Icons For Private Support.

 Procedures

 1. Add the following lines to the CONFIG.SYS file on the DOS diskette or
 partition you will boot from:

 device=drive:\os2\mdos\fsfilter.sys
 device=drive:path\dosvipx.sys
 files=214
 lastdrive=letter

     Replace drive: and path with the drive and path names where the NetWare
     Client for OS/2 files are located. Replace letter with the last local
     drive accessible to the session for NETX.EXE or Z for VLMs. NetWare drives
     start after this letter.

 NoteThe FSFILTER.SYS driver provided by OS/2 gives the DOS_STARTUP_DRIVE
 session access to OS/2 HPFS drives and Named Pipes support. See the OS/2
 documentation for more information about FSFILTER.SYS.

 2. Load the NetWare Client for DOS and MS Windows software.

     2a. Follow the directions in NetWare Client for DOS and MS Windows. Use
     the software on the NetWare Client for DOS and MS Windows diskette,
     WSDOS_1.

     2b. To load NETX.EXE for NetWare 3 support, use the software on the
     NetWare Client for OS/2 diskette, WSOS2_1. Load NETX.EXE in each session
     where you want to log in to the network.

     To autoload NETX.EXE for every session you start from a particular icon,
     use "Optional Parameters" on the "DOS Settings" notebook for that icon.

     In the "Optional Parameters" type /K followed by a space, the directory
     path, and the NETX.EXE filename. The file is then executed at the start of
     every session opened from that icon. For example, to load NETX.EXE from
     the default location, type the following:

     /K C:\NETWARE\NETX.EXE

     For more information about optional parameters, see "parameters, starting
     programs with" in OS/2 online Master Help Index.

     To autoload NETX.EXE for all DOS and MS Windows sessions, put the
     following command in an AUTOEXEC.BAT file at the root of your boot drive:

     drive:\path\NETX.EXE

     Replace drive and path with the location of your NETX.EXE file. By
     default, NETX.EXE is installed in \NETWARE with the NetWare Client for
     OS/2 files.

 NoteIf you want IPX/SPX-only support, don't load NETX.EXE. If you don't load
 NETX.EXE, you can't log in to a NetWare network, but DOS and MS Windows
 applications can use the IPX protocol.

 Network drives mapped in an OS/2 session show up as local drives in a private
 DOS_STARTUP_DRIVE session.


ΓòÉΓòÉΓòÉ 9.8. Disabling Network Support in All Virtual Sessions ΓòÉΓòÉΓòÉ

Disabling Network Support in All Virtual Sessions

To disable all network support, run the NetWare Client for OS/2 Installation
program and deselect "Support for DOS and Windows Sessions." Then reboot your
machine. This keeps VIPX.SYS and VSHELL.SYS from loading.

To re-enable support, run the install and select "Support for DOS and Windows
Sessions."


ΓòÉΓòÉΓòÉ 9.9. Setting Up Named Pipes for Virtual DOS and Windows ΓòÉΓòÉΓòÉ

Setting Up Named Pipes for Virtual DOS and Windows

Important This section applies to virtual DOS and Windows sessions only.

Virtual DOS and MS Windows sessions can function as Named Pipes clients; they
cannot function as Named Pipes servers.

If you've enabled Named Pipes support for OS/2 sessions, you automatically have
Named Pipes support for virtual DOS sessions. See "Installing Named Pipes for
OS/2"

Important: Do not load the Named Pipes extender (DOSNP.EXE) in virtual DOS and
MS Windows sessions. If you want Named Pipes support in either of the following
situations, see those sections:

 For Virtual MS Windows SQL Named Pipes Clients
 For Sessions with DOS_STARTUP_DRIVE Set


ΓòÉΓòÉΓòÉ 9.10. For Virtual MS Windows SQL Named Pipes Clients ΓòÉΓòÉΓòÉ

For Virtual MS Windows SQL Named Pipes Clients

Verify that the NETAPI.DLL file from the \WINDOWS subdirectory on the WSOS2_1
diskette was copied to one of the following locations on your hard disk:

      The \OS2\MDOS\WINOS2 subdirectory (which contains WINOS2.COM)

      The \OS2\MDOS\WINOS2\SYSTEM subdirectory (which contains the MS Windows
     KERNEL.EXE)

      The directory of the application that runs Named Pipes

 Warning This NETAPI.DLL is an MS Windows file, not an OS/2 file, and is
 provided specifically for MS Windows SQL Named Pipes Windows clients. Do not
 copy it over the NETAPI.DLL in the \NETWARE directory.


ΓòÉΓòÉΓòÉ 9.11. For Sessions with DOS_STARTUP_DRIVE Set ΓòÉΓòÉΓòÉ

For Sessions with DOS_STARTUP_DRIVE Set

Sessions set with DOS_STARTUP_DRIVE boot from a version of DOS other than the
one included in OS/2. The OS/2 online "Master Help Index" explains more about
the DOS_STARTUP_DRIVE feature.

If you use DOS_STARTUP_DRIVE to boot a session, you do not need to get Named
Pipes support from Novell. Instead, load the FSFILTER.SYS driver provided by
OS/2.

Load the FSFILTER.SYS driver in the CONFIG.SYS file for the DOS_STARTUP_DRIVE
session. (CONFIG.SYS is bound into the image file you boot the session from.
See your OS/2 documentation.)

To load the FSFILTER.SYS driver, do the following:

Procedure

1. Open CONFIG.SYS for the DOS_STARTUP_DRIVE session in a text editor.

2. On a new line in the file, type a line to load FSFILTER.SYS.

For example, type

DEVICE=C:\OS2\MDOS\FSFILTER.SYS

3. Save and exit CONFIG.SYS

See your OS/2 documentation for more information about loading FSFILTER.SYS in
CONFIG.SYS.

Important: Do not load the Novell Named Pipes Extender for DOS in the
DOS_STARTUP_DRIVE session. It will conflict with the OS/2 Named Pipes driver.


ΓòÉΓòÉΓòÉ 9.12. Setting Up NetBIOS for Virtual DOS and MS Windows ΓòÉΓòÉΓòÉ

Setting Up NetBIOS for Virtual DOS and MS Windows

This section applies to virtual DOS and MS Windows sessions under OS/2 only. To
set up NetBIOS on an actual DOS or MS Windows workstation, see the NetWare
Client for DOS and MS Windows documentation.

NetWare Client for OS/2 and the IBM LAPS program both support the NetBIOS
protocol in a virtual session. However, the type of support is different.

NetWare NetBIOS Support

NetWare NetBIOS support is not virtualized. This means that the session will
not use the same NetBIOS driver that is used by OS/2 sessions.

Instead, you must load the NETBIOS.EXE TSR program in the session, just as you
would to get NetBIOS support on an actual DOS workstation.

When you use NETBIOS.EXE in a virtual session, you can't get NetBIOS
connections from OS/2 sessions or from any other DOS or MS Windows sessions
until NETBIOS.EXE is unloaded. You will only have one NetBIOS connection from a
single virtual session. This is true even if your OS/2 NetBIOS driver appears
to be loaded.

As the following diagram shows, NetWare NetBIOS support for a single DOS
session goes through NETBIOS.EXE and VIPX.

IBM LAPS NetBIOS Support

Prerequisites

Γûá Enable IPX support for virtual sessions. See "Customizing Icons for Global
Support" or "Customizing Icons For Private Support."

ΓûáDisable NetBIOS support for OS/2 sessions. Novell's NetBIOS solution for DOS
boxes is not virtual and doesn't allow other NetBIOS drivers to be running at
the same time. Disable NetBIOS support by running the NetWare Client for OS/2
installation program and deselecting "NetBIOS Emulation for OS/2." "Setting Up
the Novell NetBIOS Driver" explains how to run the installation program.

Procedure Follow the instructions in the NetWare Client for DOS and MS Windows
manual. Use that documentation to

1. Load NETBIOS.EXE in a single DOS session.

2. Configure NetWare NetBIOS for DOS if necessary.

The LAPS NetBIOS support is virtualized, meaning that you do not have the
single-connection limitation. You do not have access to this virtualized
support unless you have the LAPS protocols, included with both Extended
Services and LAN Services from IBM.

As the following diagram shows, LAPS virtual NETBIOS support goes through
LANVDD and LANPDD. It uses the NETBIOS.OS2 interface to communicate with either
the Novell or IBM NetBIOS driver.

LAPS NetBIOS support follows the NetBIOS 3.0 (NB30) standard. You can run
NetBIOS applications in a virtual session even if those applications do not
conform with NB30. However, the need for increasing resources in a session is
more likely when running non-NB30 applications.

Avoiding Resource Errors

Your virtualized NetBIOS sessions can be supported by Novell's OS/2 NETBIOS.SYS
driver or by Extended Services's OS/2 NETBEUI.OS2 driver or by both.

When virtual sessions are supported by Novell's OS/2 NetBIOS driver, be aware
of a potential resource limitation.

noteIf you have previously followed the steps in Configuring NETBIOS.OS2 with
PROTOCOL.INI, you are using Novell's driver.

LAPS NetBIOS support for virtual sessions follows the NetBIOS 3.0 (NB30)
standard. Among other things, a NetBIOS 3.0 application reserves a certain
number of names, commands, and sessions when it first executes.

If you run NetBIOS applications in several virtual sessions, all resources in
one of the NetBIOS components must be reserved and additional applications will
not run. You see a resource error when you try to make NetBIOS connections.

You can minimize the possibility that NetBIOS will run out of resources by
doing both or either of the following:

      Whenever you're using virtual NetBIOS connections, increase the default
     resources allowed for the NETBIOS driver in NET.CFG.

     Configuring the Driver explains how to increase the defaults for the OS/2
     NetBIOS driver.

      Specify the resources consumed for each virtual session you use. How to
     specify resources is explained below.

 Prerequisites

 Checklist  Install Extended Services with NetBIOS support. See the Extended
 Services documentation.

  Install LAN Services if you have it. See the LAN Services documentation.

  Install NetWare Client for OS/2 with NetBIOS support. Setting Up the Novell
 NetBIOS Driver explains how to do this.

  Configure NETBIOS.OS2 to use both Novell and IBM drivers. Configuring
 NETBIOS.OS2 with PROTOCOL.INI explains how to do this.

 Procedures

 These instructions explain how to set resource information for Extended
 Services virtualized NetBIOS. This information is stored with a program called
 LTSVCFG.COM.

 The LTSVCFG.COM program is included with LAPS in Extended Services and LAN
 Services.

 Procedure

 1. Open the virtual session.

 2. Execute LTSVCFG.COM with the command line parameters you need.

 For example, to set the number of NetBIOS commands to 12, type the following:

 LTSVCFG.COM C=12

 Three parameters that apply to NetBIOS resources are:

 s="number of NetBIOS sessions"
 n="names"
 c="commands"

 For more information about these and other NetBIOS parameters, see the LAPS
 documentation on NetBIOS.

 Important You cannot set parameters for LTSVCFG.COM to amounts higher than
 amounts set for the NETBIOS.OS2 or NETBIOS.SYS driver. The default sessions,
 names, and commands settings for the NETBIOS.SYS driver are:

 Sessions=16
 Names=24
 Commands=32

 You may have changed these defaults in your NET.CFG file.


ΓòÉΓòÉΓòÉ 10. Backing Up Your Workstation ΓòÉΓòÉΓòÉ

Backing Up Your Workstation

Overview

The network supervisor or backup supervisor can back up your OS/2 workstation
to the network. To allow access, run the NetWare TSA_OS2 (Target Service Agent)
program on your workstation.

The TSA_OS2 program runs as an application in an OS/2 session. You can continue
working in other sessions while TSA_OS2 is running on your workstation.
Whenever the TSA_OS2 is running, SBACKUP or another backup program can access
the hard drive data.

The TSA_OS2 is installed automatically on the hard drive when you install the
NetWare Client for OS/2 software. An icon for the TSA_OS2 is placed in the
Novell group on your desktop.

With the TSA_OS2 program, you can specify:

Γûá Which users on the network can access your hard drive

Γûá What password must be typed in the backup program before accessing your hard
drive

Γûá Which drives on the hard disk can be backed up

Starting TSA_OS2 Manually

This section explains how to start TSA_OS2 manually by choosing its icon on
your desktop.

Prerequisites

 Load TSA_OS2.NLM on the server. See Supervising the Network for more
information.

 Install NetWare Client for OS/2.

Procedure 1. Choose the "Novell" icon on your OS/2 desktop.

     The "Novell-Icon View" window appears.

 2. From the "Novell-Icon View" window on your desktop, choose the NetWare TSA
 icon for the TSA_OS2.EXE program.

     The TSA_OS2 main window appears.

 3. Choose the features you want from the menu bar.

     For more information about this feature, choose "Help.".

 Starting TSA_OS2 Automatically

 You can set up TSA_OS2 to start each time you boot your machine. To do this

 Γûá Place your TSA_OS2 icon in the "Startup" folder. This section explains how
 to put the icon in the "Startup" folder.

 Γûá Set up your TSA_OS2.CFG file. Setting up your TSA_OS2.CFG file is explained
 in the next section.

 Prerequisites

  Load the TSA_OS2.NLM on the server. See Supervising the Network for more
 information.

  Install NetWare Client for OS/2.

 Procedure 1. Open the "OS/2 System" folder on your desktop.

     The "OS/2 System" window appears.

 2. Open the "Startup" folder from the "OS/2 System" window.

     The "Startup" window appears.

 3. Without closing the "Startup" window, open the "Novell" group on your
 desktop.

     The "Novell" window appears.

 4. Drag the TSA_OS2.EXE icon from the "Novell-Icon View" window into the
 "Startup" folder.

     Whenever you reboot your workstation, the TSA_OS2 program will start
     automatically.

 Important If backups at your site are done after hours, remember to leave the
 OS/2 workstations turned on or the backup supervisor will not be able to
 access the hard disk.

 Setting Up Your TSA_OS2.CFG File

 You can create a text file called TSA_OS2.CFG to store settings for TSA_OS2.
 These settings are read by TSA_OS2 each time the program starts up. The
 parameters you can type in the configuration file are listed below.

 List of TSA_OS2.CFG parameters

 WSName

     The Target Service name you assign to your workstation. Do not use spaces
     in the workstation name.

          WSName JO_OS2

 ServerName

     The name of the server where the Target Service Agent Router NLM is
     loaded.

          ServerName SALES_MKTG

 UserName

     The User objects you allow to attach to the OS/2 workstation. Repeat this
     line for each User object. If you want to specify a password, specify it
     on the same line as the username.

     The username must be one defined on the network. The password is unique to
     your workstation, not the same password the user types to access the
     network. If you specify a password, the backup administrator will have to
     type that password in the backup program.

                    UserName NANCY
                    or to set a password of NEATO:
                    UserName NANCY NEATO

 HideResource

     The drives you do not want to be backed up. Repeat this line for each
     drive. The colon after the driver letter is allowed, but not required.

          HideResource C
          HideResource D:

 AutoRegister

     Automatically register with the Target Service Router NLM on the server
     whenever your workstation boots. To use this parameter, specify a valid
     WSName, ServerName, and UserName.

                    AutoRegister ON
                    or
                    AutoRegister OFF

 TempFilesDir

     The location on your hard drive where the backup program can temporarily
     store files during backup. These files are removed when backup is
     completed. Do not use spaces in the directory name.

     If you do not specify this parameter, the temporary directory is located
     in the root of the directory where you executed TSA_OS2.EXE.

          TempFilesDir C:\TEMP_TSA

 The following is a sample TSA_OS2.CFG configuration file:

                    WSName Joe's_Machine
                    ServerName SALES_MKTG
                    UserName FredJ
                    UserName Mark
                    UserName admin
                    UserName nancy NEATO
                    HideResource c:
                    hideresource b:
                    AUTOREGISTER on
                    tempfilesdir c:\temp_os2

 The file is not case-sensitive.


ΓòÉΓòÉΓòÉ 11. Using Remote Program Load ΓòÉΓòÉΓòÉ

Using Remote Program Load

Topics Discussed

Prerequisites

Creating Users and Granting Rights

Installing OS/2 Files for RPL Workstations

Installing RPL Files for RPL Workstations

Setting Up RPL Workstations

Using RPL on Workstations with Hard Disks

Configuring NetWare Client for OS/2 for RPL Workstations

Overview

ImportantTo install Remote Program Load (RPL), you must have Supervisor object
rights to the NetWare Server(s) that the workstation will attach to.

RPL lets OS/2 workstations boot from network hard disks rather than booting
from a local hard disk.

What Happens When You Add RPL Workstations

When you add RPL workstations to a network, the following actions occur:

Γûá Directories are created.

Γûá Files are created.

Γûá Files are copied.

Γûá CONFIG.SYS is copied and modified.

Directories Are Created

If you have not installed RPL workstation support, the SYS:RPL2 and the \USER
and \COMPUTER directories will be created on each server.

Also the following directories will be created for each workstation you add:

Γûá A user's home directory under the \USER directory.

     This directory has the same name as the username you specify. For example,
     a user named JADAMS would have a home directory of

     SYS:RPL2\USER\JADAMS

     If a logical name was specified (for example, LAB_1), then the home
     directory would be

     SYS:RPL2\USER\JADAMS\LAB_1

 Γûá A user's node address directory under the \COMPUTER directory.

     This directory has the same name as the last 11 characters of the
     workstation node address. For example, if the node address is
     2223345BBBBB, the node address directory would be

     SYS:RPL2\COMPUTER\223345BB.BBB

 Γûá A subdirectory containing the OS/2 desktop in each user's home directory.

     This directory is called OS!2_2.0_D if you're installing from a FAT drive
     and "OS2 20 Desktop" if you're installing from an HPFS drive.

 Γûá A \SPOOL subdirectory in each user's home directory.

     This directory contains all desktop printing files.

 Files Are Created

 Γûá A file called CONFIG.WSS is created in each user's node address directory on
 the server.

     This file tells OS/2 to use the OS2.INI, OS2SYS.INI, and CONFIG.SYS files
     from the user's home directory on the network instead of trying to find
     these files in their regular locations on a local drive.

     It also tells OS/2 to use the desktop files and \SPOOL subdirectory from
     the user's home directory on the network rather than from a local hard
     disk.

 Γûá A BOOTCONF.SYS file is created in the SYS:LOGIN directory.

     If a BOOTCONF.SYS file exists (from other installations of RPL
     workstations), the information for the new workstations is added to the
     beginning of the file.

     This file tells the server which boot image file to use for each
     workstation and contains lines identifying which RPL workstation uses
     which type of network board. For example, a line for an NE2000 workstation
     might be as follows:

     0xDOC20,1b0276A32222=NE2000.RPL

     See Format of BOOTCONF.SYS File for an explanation of the lines in the
     BOOTCONF.SYS file.

     Files Are Copied

     All files in the \DESKTOP and \SPOOL subdirectories are copied from the
     local drive of the OS/2 workstation to the server. Also, all files in
     CONFIG.WSS are copied.

     These files allow RPL workstations to load customized versions of OS/2 and
     the OS/2 desktop.

     CONFIG.SYS Is Copied and Modified

     A CONFIG.SYS file is copied from the local drive of the OS/2 workstation
     you are installing from to each user's subdirectory on each server.

     This CONFIG.SYS is modified slightly for each user. The line that loads
     HPFS is commented out, and the directory in the SWAPPATH line is changed.

     This CONFIG.SYS is modified for each user. The line that loads HPFS is
     commented out, and the directory in the SWAPPATH line is changed.

     All lines beginning with IFS= are commented out before the IFS=NWIFS line.
     The NWIFS line must be the first installable file system loaded.

     If the user wants to run a CD-ROM drive from the RPL workstation, the
     IFS=CDFS line must be moved to after the NetWare Requester statements in
     CONFIG.SYS.

     Also, disk caching is turned off and the ODI driver is changed to the
     driver you selected.

     Directory Structure for RPL Workstation Support shows the complete network
     directory structure for remote workstations.


ΓòÉΓòÉΓòÉ 11.1. Prerequisites ΓòÉΓòÉΓòÉ

Prerequisites

Three computers are needed to install an RPL workstation:

Γûá The server that the RPL workstation will attach to

Γûá A computer with OS/2 and NetWare Client for OS/2 installed that can access
the server (referred to as the client workstation).

Γûá A computer to be used as the RPL workstation refered to as the RPL
workstation.

There are prerequisites for each of these three computers.

Prerequisites for the NetWare Server

Checklist  The server must be running either NetWare 3 or 4.

 You must have Supervisor object rights to the server that the RPL workstation
will attach to.

 Enough disk space must be on the server for RPL workstation installation. You
need 30 MB for OS/2 plus enough space for additional files you need.

Prerequisites for the Client Workstation

Checklist

 Make sure OS/2 is installed on the workstation C: drive. It must be drive C:.

 Make sure that NetWare Client for OS/2 is installed in the \NETWARE
directory.

 Make sure the client workstation is connected to the server.

 If drive C: has HPFS, make sure the OS/2 name space is loaded for volume SYS:
or the server where the remote workstation files will be installed.

 Move or delete all your personal files that are on drive C:. (The
installation program copies all files from drive C: to the server.)

 Make sure the desktop is arranged in the way you want the RPL workstation to
appear. The RPL workstation's desktop will look like the desktop of the
workstation you're installing from.

 Make sure the workstation only loads the programs that the RPL workstations
need. Programs can be loaded from CONFIG.SYS, .CMD files, or the Startup
folder.

 Make sure all programs needed by RPL workstations are located on drive C:
(this only applies to programs on the hard drive). For example, make sure your
E-mail program on C:\EMAIL does not store mail files in the D:\MYMAIL directory
or use E:\TEMP for initialization files. The RPL workstations will not have
drives D: or E: available.

 If you set up PS/2 computers as RPL workstations, obtain an OS/2 installation
diskette . If you use PS/2 computers as RPL workstations, the program copies
some files form this diskette.

Prerequisites for the RPL Workstation

Checklist  RPL workstations must have network boards with Remote Boot PROMs
attached. Remote Reset PROMs allow workstations to connect to the network so
that boot information can be accessed.

 Determine the type of Remote Boot PROM you have. The RPL workstation
installation will ask if you have a "New Enhanced Boot PROM" or an "Older Style
Boot PROM." Older Style Boot PROMs were made before 1992. If you don't know
what type of PROM you have, find the part number and call the PROM
manufacturer.

noteIBM token ring EPROMS are always considered New Enhanced Boot PROMs, no
matter what year they were manufactured.

 If you have New Enhanced Boot PROMs, make sure RPL.NLM is loaded on the
server. Older style boot PROMs don't require RPL.NLM.

 Make sure the workstation is cabled to the network.

 Make sure you know the network and node address of the RPL workstation.

Determining Boot PROM Types

IBM Boards

          You can use RPL with the following IBM boards:

          Γûá PCN2L

          Γûá TOKEN

          These boards are always considered new enhanced boot PROMs.

 Novell Boards

          You can use RPL with the following Novell boards:

          Γûá NE1000

          Γûá NE2000

          Γûá NE/2

          These boards can have either new enhanced boot PROMs or older style
          boot PROMs.

 Loading RPL.NLM for IBM Boards or New Enhanced Boot PROMs

 Important If you use IBM boards or Novell boards that support New Enhanced
 Boot PROMs, use the following procedure.

 To set up the server to use RPL with this type of workstation, load and bind
 the RPL loadable module on each server.

 Procedures 1. At the server console, type

     LOAD RPL

 NoteRPL.NLM is shipped with NetWare Client for OS/2. It is on WSOS2_1 in the
 RPL directory.

 2. Type

     BIND RPL TO driver PS=servername NODEFAULT

     Replace driver with the name of a LAN driver in your server. To bind more
     than one driver, use additional bind statements.

     Replace servername with the name of the server that has the RPL files.

 3. For Ethernet PROMs, bind RPL to the 802.2 frame type.

 NoteThe first frame type in NET.CFG must correspond to the frame type that RPL
 is bound to. For example, if you typed at the server console prompt:

 BIND RPL TO NE2000 [FRAME=ETHERNET_802.2]

 The NET.CFG setting on the workstation should look like

 link driver ne2000
     frame ethernet_802.2

 Where Ethernet_802.2 is the first frame type listed.

 For more information about the RPL loadable module, see NetWare Utilities
 Reference manual.


ΓòÉΓòÉΓòÉ 11.2. Creating Users and Granting Rights ΓòÉΓòÉΓòÉ

Creating Users and Granting Rights

NoteThis procedure only works for NetWare 4 users. NetWare 3 users should use
SYSCON.EXE.

ImportantTo complete the RPL installation, you must have Supervisor object
rights to the server that the RPL workstation will attach to.

You must set up accounts for RPL workstations. Do the following:

Procedures

1. Create the RPL User object.

     1a. From the attached client workstation, log in.

     1b. At the C:> prompt, type NWADMIN.

          The "NetWare Administrator" window appears.

     1c. Highlight the Container object that will contain the new user.

     1d. From the "Object" menu, choose "Create"

        The "New Object" window appears.

     1e. Select the "User" icon.

     1f. Choose "OK"

        The "Create User" window appears.

     1g. In the "Login Name" field, type RPL.

        RPL is the username each RPL workstation uses to make the initial
        connection to the network.

     1h. In the "Last Name:" field, type RPL.

     1i. Choose "Create."

        You are returned to the "NetWare Administrator" window.

 2. Repeate Steps 1c through 1i to create a User object for each person who
 will use a RPL workstation.

 3. Grant access to the RPL User.

 ImportantDo not require a password for the RPL User object, or the RPL
 workstations can't make the connection. Protect the account by granting
 limited access, as explained in Step 4.

 The RPL user needs at least read and file scan access to

 Γûá The SYS:RPL2 directory

 Γûá The SYS:RPL2\COMPUTER directory and all its subdirectories

 These directories are created automatically during RPL workstation
 installation.

 4. Grant minimal access rights to each RPL workstation user.

 All RPL workstations need

 Γûá File scan and read access to the SYS:RPL2 directory

 Γûá File scan and read access the \OS2 and \NETWARE subdirectories under
 SYS:RPL2

 Γûá Supervisory access rights to their home directories under SYS:RPL2\USER

 These directories are created automatically during RPL workstation
 installation.

 Users do not have to be given access to other users' home directories under
 SYS:RPL2\USER

 Supervising the Network explains more about NetWare security and granting and
 prohibiting access.

 Warning Since the SYS:RPL2 directory becomes the root of drive C: for all RPL
 workstations, all RPL users require access to this area. Do not store
 confidential files in this directory. Instead, store them in another network
 directory where access can be restricted.

 You may want to warn users about this lack of privacy and encourage them to
 store data in their home directories (for example, C:\USER\MARY) or in another
 location on the network.


ΓòÉΓòÉΓòÉ 11.3. Installing OS/2 Files for RPL Workstations ΓòÉΓòÉΓòÉ

Installing OS/2 Files for RPL Workstations

What Happens When You Install OS/2 Files

When you install OS/2 files for RPL workstations, the following actions occur:

Γûá A SYS:RPL2 directory is created on each server you select.

     All RPL workstations use this directory as if it is their local boot
     drive. Once RPL users log in, they can access all information in this
     directory.

     Since the SYS:RPL2 directory is on the server and not on a local disk,
     NetWare security still applies. For example, you can limit RPL users'
     access to specific directories and files. "Creating Users and Granting
     Rights" explains more about securing the SYS:RPL2 directory and its
     subdirectories.

 NoteOS/2 1.3 RPL workstations used a directory called SYS:RPL. This directory
 is not erased when the SYS:RPL2 directory is created. OS/2 version 1.3 RPL
 workstations and OS/2 version 2.10 RPL workstations can both boot on the same
 network.

 Γûá Every file from workstation drive C: is copied to the SYS:RPL2 directory on
 the server.

 Complete the steps in this section if you are

 Γûá Setting up RPL workstations for the first time.

 Γûá Upgrading existing RPL workstations from OS/2 1.3 to OS/2 2.x.

 Γûá Upgrading OS/2 on the server (i.e. from OS/2 2.0 to OS/2 2.1).

 Γûá Adding a server to the network where RPL workstations attach (only for the
 server you add).

 Important If you use older style boot PROMS, don't do the steps in this
 section every time you add an RPL workstation to the network. See Setting Up
 RPL Workstations.

 Important RPL files must be installed on all network servers. If some servers
 don't use RPL support, use the following SET paramter at each server's console
 prompt, or include in each server's AUTOEXEC.NCF file, and the servers will
 not respond to remote PROMs:

 SET RESPOND TO GET NEAREST SERVER = OFF

 If you set this parameter on each server, the server will not respond to
 Remote Reset PROMs and it can't boot RPL workstations, but you won't need to
 install the files for RPL workstations support on that server. For more
 information about the SET command, see Utilities Reference.

 We recommend that you establish a separate physical network for RPL users. Put
 only the servers on this network that are need to support the number of RPL
 users you have. If you want, connect this network to other networks at your
 site through routers. This setup saves time and server space.

 Procedures

 1. On the client workstation, log in to the server where you want the OS/2
 files for RPL workstations.

 2. Open the NetWare Requester for OS/2 installation program.

     The "NetWare Requester for OS/2 Installation Utility" window appears. Use
     the online help as necessary.

 3. From the "Installation" menu, choose "Remote workstations. . ."

     The "Remote Workstation Installation" window appears.

 NoteThe "Copy All Files and Setup Workstation..." option has three separate
 components: copying OS/2 files, copying RPL files, and setting up RPL
 workstations. Each of these procedures are explained individually.

 4. Select "Only Copy OS/2 Files . . . " and choose "OK"

     You can choose other actions from the "Remote Workstation Installation"
     screen.

 5. Choose the servers you want the files copied to.

     You are attached to the servers you select. The files must be installed on
     all servers on the local net (cable segment with same address).

 6. Choose "OK."

     All OS/2 and NetWare Client for OS/2 files are copied to the servers.

 7. After the files are copied, do the following.

 If you want to . . .
      Do this . . .

 Copy RPL files
      Without exiting the installation program, go to Installing RPL Files for
      RPL Workstations

 Add RPL workstations to the network
      Without exiting the installation program, go to Setting Up RPL
      Workstations

 Configure NetWare Client for OS/2 for RPL workstations
      Without exiting the installation program, go to Configuring the NetWare
      Client for OS/2 for RPL Workstations

 Exit the installation program
      Choose "Close" from the system menu in the upper left corner of the
      Installation window.


ΓòÉΓòÉΓòÉ 11.4. Installing RPL Files for RPL Workstations ΓòÉΓòÉΓòÉ

Installing RPL Files for RPL Workstations

What Happens When You Install RPL Files

When you use the installation program to install RPL workstation support, the
following actions occur.

Γûá Directories are created.

Γûá Files are copied.

Directories Are Created

Γûá SYS:RPL2 is created if it doesn't already exist

Γûá The \USER and \COMPUTER subdirectories are created under SYS:RPL2 on each
server.

See Directory Structure for RPL Workstation Support for the complete directory
structure created when you install remote workstation support and add RPL
workstations.

 Files Are Copied

 The following RPL files are copied to the SYS:LOGIN directory:

 Γûá NE2.200
 Γûá NE2000.200
 Γûá NE1000.200
 Γûá RPLOS2.200
 Γûá RBOOT.RPL
 Γûá ETHER.RPL
 Γûá TOKEN.RPL

 These files have different names than the RPL files used to boot OS/2 1.3.
 OS/2 1.3 RPL boot files are also located in the SYS:LOGIN directory.

 The following files are copied to the SYS:RPL2 directory:

 Γûá MINI.IFS
 Γûá MICRO.IFS

 Procedure

 Complete the steps in this section if you are:

 Γûá Setting up RPL workstations for the first time.

 Γûá Upgrading existing RPL workstations from OS/2 1.3 to OS/2 2.x.

 Γûá Installing a new version of NetWare Client for OS/2.

 Γûá Adding a server to the network where RPL workstations attach (only for the
 server you add).

 Don't do the steps in this section every time you want to add an RPL
 workstation to the network. See Setting Up RPL Workstations.

 Important All RPL files must be installed on each server on the network. There
 is no way to specify which server an RPL workstation will initially establish
 a connection with.

 We recommend that you establish a separate physical network for RPL users. Put
 only the servers on this network that are needed to support the number of RPL
 users you have. If you want, connect this network to other networks at your
 site through routers. This setup saves time and server space.

 Procedures:

 1. On the client workstation, open the NetWare Client for OS/2 installation
 program.

     The "NetWare Requester for OS/2 Installation Utility" window appears. Use
     online help as necessary.

 2. From the "Installation" menu, Choose "Remote workstations. . ."

     The "Remote Workstation Installation" window appears.

 NoteThe Copy All Files and Setup Workstations... option has three separate
 components: copying OS/2 files, copying RPL files, and setting up RPL
 workstations. Each of these procedures are explained individually.

 3. Choose "Only Copy RPL Files . . ."

     You can also choose other actions from the "Remote Workstation
     Installation" screen.

 4. Choose the servers you want the RPL files copied to.

     You will be attached to the servers you select. The RPL files must be
     installed on all servers on the local net (cable segment with same
     address).

 5. Choose "OK."

     All RPL boot files are copied to the servers.

 6. Select the source drive for the RPL files.

     The default is the drive where INSTALL.EXE was loaded. If you loaded
     INSTALL.EXE from the hard drive, change this to your floppy drive and
     insert the first installation diskette in it.

 7. Choose "OK".

 8. After the files are copied, do the following.

 If you want to . . .
      Do this . . .

 Add RPL workstations to the network
      Without exiting the installation program, go to Setting Up RPL
      Workstations

 Configure NetWare Client for OS/2 for RPL workstations
      Without exiting the installation program, go to Configuring the NetWare
      Client for OS/2 for RPL Workstations

 Exit the installation program
      Choose "Close" from the system menu in the upper left corner of the
      Installation window.


ΓòÉΓòÉΓòÉ 11.5. Setting Up RPL Workstations ΓòÉΓòÉΓòÉ

Setting Up RPL Workstations

What Happens When You Set Up RPL Workstations

Each RPL workstation you boot from the network must be added to the RPL setup
on the network. You identify to each server the user for that workstation, the
node address, and the network board.

RPL workstations are added by running the NetWare Client for OS/2 installation
program from a workstation that has OS/2 installed on drive C:.

Complete the steps in this section on each server if you are

Γûá Setting up RPL workstations for the first time

Γûá Upgrading existing RPL workstations from OS/2 1.3 to OS/2 2.x

Γûá Adding RPL workstations to the network

NoteWhenever possible, use the same type of network board in all RPL
workstations. This saves you time when you install and configure RPL
workstations.

If the installation program is already running, go to Step 4.

Procedure

1. Log in from the client workstation.

2.Open the "Novell" group icon on the desktop.

3.Choose the "Install" icon in the "Novell-Icon View" window.

     The "NetWare Workstation for OS/2 Installation Utility" window appears.

 4. From the "Installation" menu, choose "Remote workstations. . ."

     The "Remote Workstation Installation" menu appears.

 NoteThe Copy All Files and Setup Workstations... option has three separate
 components: copying OS/2 files, copying RPL files, and setting up RPL
 workstations. Each of these procedures are explained individually.

 5. Choose "Only SetUp Workstations. . ."

 6. Choose "OK."

     The "Select 1 or More File Servers" window appears.

 7. Choose servers on which you want to define RPL workstations.

     For a list of available servers, choose "Attach." Then choose the arrow at
     the end of the "Server name" field. For more information, use the online
     help.

 8. When you've selected all the servers you want, choose "OK."

     The "Select the type of BOOT PROM in the target workstation" window
     appears.

 9. Select the type of BOOT PROM you have.

     If you have an IBM board or if the board was manufactured during or after
     1992, select "New Enhanced BOOT PROM"

      If your board was manufactured before 1992, Select "Older style BOOT
     PROM".

     If you aren't sure what type of board you have, find the board's part
     number and contact the board's manufacturer.

 Important If you use token ring, the boot PROM is always considered as a New
 Enhanced Boot PROM, no matter when it was manuractured.

 10. Choose "OK."

     The "Add Remote Boot Workstation" window appears.

     Different versions of this window appear, depending on the type of BOOT
     PROM you selected in Step 9.

 11. Complete all fields in the window.

 NoteUser name should be the actual name or login name of the person you are
 setting up the RPL workstation for. Logical Name becomes the name of the
 subdirectory under that user.

 For example, if you set up the user name as SUSAN and the logical name is LAB,
 the path would read RPL2\USER\SUSAN\LAB.

 12. Choose "Add."

 13. Exit the installation program.

 Using an RPL Workstation with Virtual DOS

 RPL workstations are unable to remap drive C:. Even if you are using global
 DOS, RPL workstations treat global DOS the same as private DOS.

 For example, if you were in global DOS and remapped drive C:, the remapped
 drive C: will not show up when you go to a private DOS session.


ΓòÉΓòÉΓòÉ 11.6. Using RPL on Workstations with Hard Disks ΓòÉΓòÉΓòÉ

Using RPL on Workstations with Hard Disks

To use RPL on a workstation with a hard disk, label your hard drive a drive
other than C:. Drive C: must be assigned to the SYS:RPL2 network directory.
OS/2 thinks this network directory is the local drive C:.

Also, you may need to determine whether your hard disk has an operating system
or not, you can format it (FAT) and use it to store your OS/2 SWAPPER.DAT file.
This will cut down on network traffic.

Locating SWAPPER.DAT Locally

Procedure  1. Go to the home directory on the network for the user who will be
using the RPL workstation.

     For example, if JOHN will be using the RPL workstation with a hard drive,
     go to the following directory:

     SYS:RPL2\USER\JOHN

     Each user's home directory on the network contains that user's CONFIG.SYS
     file and several other OS/2 files. Directory Structure for RPL Workstation
     Support shows a complete directory structure.

 2. Using a text editor, open the CONFIG.SYS file.

 3. In the CONFIG.SYS file, find the line that designates the SWAPPATH.

     You can search for SWAPPATH. The line looks like the following:

     SWAPPATH=C:\USER\JOHN 2048 2048

     Remember that to OS/2, the SYS:RPL2 directory is drive C:.

 4. Change the SWAPPATH line to point to the local hard drive.

     For example, to point to the root of local drive D:

     SWAPPATH=D:\ 2048 2048

 5. Save and exit the CONFIG.SYS file.

     When you boot the RPL workstation, the SWAPPER.DAT will be stored locally.


ΓòÉΓòÉΓòÉ 11.7. Configuring NetWare Client for OS/2 for RPL Workstations ΓòÉΓòÉΓòÉ

Configuring NetWare Client for OS/2 for RPL Workstations

Configure NetWare Client for OS/2 for RPL workstations by running the NetWare
Client for OS/2 installation program and choosing "Remote workstations . . ."
from the "Configuration" menu.

When you configure RPL workstations, the NetWare Client for OS/2 installation
program puts a NET.CFG configuration file in the home directory of the users
you specify. The home directory is located under SYS:RPL2\USER on each server
on the local network.

The NET.CFG you create with the installation program should be identical on all
servers on the local network so RPL workstations boot the same way each time.

For example, if user JOHN has a NET.CFG file in his user directory on SERVER1,
then a copy of the same NET.CFG file should be placed in his home directory on
SERVER2.

The installation program puts a line in each user's CONFIG.WSS file in the
workstation subdirectory, telling NetWare Client for OS/2 where to find the
NET.CFG file. For example, for John's NET.CFG file, the installation program
puts in the following line:

C:\NET.CFG C:\USER\JOHN\NET.CFG

Important Remember that the SYS:RPL2 directory becomes the root of the C:
drive. If the RPL workstation is using the Ethernet frame type, the frame type
specified in the NET.CFG file must be the same as the frame type used by the
PROM. New Enhanced Boot PROMs use 802.2. Older style boot PROMs use 802.3.


ΓòÉΓòÉΓòÉ 11.7.1. Directory Structure for RPL Workstation Support ΓòÉΓòÉΓòÉ

Directory Structure for RPL Workstation Support


ΓòÉΓòÉΓòÉ 11.7.2. Format of BOOTCONF.SYS file ΓòÉΓòÉΓòÉ

Format of BOOTCONF.SYS file


ΓòÉΓòÉΓòÉ 12. Improving Speed and Security ΓòÉΓòÉΓòÉ

Improving Speed and Security

This chapter discusses three features that help to improve speed and security
on your network.

Improving Speed by Using Packet Burst

Improving Speed by Using Large Internet Packets

Improving Security by Using NCP Packet Signature


ΓòÉΓòÉΓòÉ 12.1. Improving Speed by Using Packet Burst ΓòÉΓòÉΓòÉ

Improving Speed by Using Packet Burst

Packet Burst is a protocol that speeds the transfer of multiple-packet NCP
reads and writes. Packet Burst eliminates the need to sequence and acknowledge
each packet. With Packet Burst, the server or client sends a whole set (or
burst) of packets before it requires an acknowledgment.

Packet Burst reduces network traffic by allowing multiple packets to be
acknowledged. Packet Burst also monitors dropped packets and retransmits only
the missing packets.

At connection time, maximum burst sizes are negotiated with each server. Since
Packet Burst is established with each connection, it's possible to "burst" with
one server but not with another.

Once you establish a Packet Burst connection between a workstation and a
server, the workstation automatically uses Packet Burst whenever an application
requests to write more than three times the maximum packet size of data. This
means that an application doesn't have to be aware of Packet Burst.

Disabling Packet Burst

Packet Burst is enabled at the workstation by default. You can disable it by
adding the following to the workstation's NET.CFG file:

     netware requester
        packet burst off


ΓòÉΓòÉΓòÉ 12.2. Improving Speed by Using Large Internet Packets ΓòÉΓòÉΓòÉ

Improving Speed by Using Large Internet Packets

Large Internet Packet (LIP) functionality allows the internet packet size to be
increased from the default 576 bytes. By allowing the NetWare packet size to be
increased, LIP enhances transmission over bridges and routers.

In NetWare 4, the workstation requests an acceptable packet size. However,
unlike previous versions of NetWare, the NetWare server doesn't default to 576
bytes when a router is detected.

Instead, the workstation attempts to send larger packets to the server. The
largest packet size that the server accepts is the packet size used to
communicate.

Disabling Large Internet Packets

LIP functionality is enabled by default on the workstation. To disable it,
enter the following to the NET.CFG file:

     netware requester
        large internet packets off


ΓòÉΓòÉΓòÉ 12.3. Improving Security by Using NCP Packet Signature ΓòÉΓòÉΓòÉ

Improving Security by Using NCP Packet Signature

NetWare Core Protocol (NCP) Packet Signature is an enhanced security feature
that protects servers and clients using NCP by preventing packet forgery.

Without NCP Packet Signature, a network client can pose as a more privileged
client to send a forged NCP request to a NetWare server. By forging the proper
NCP request packet, an intruder could gain Supervisor rights and access to all
network resources.

NCP Packet Signature prevents packet forgery by requiring the server and the
client to "sign" each NCP packet. The packet signature changes with every
packet.

NCP packets with incorrect signatures are discarded without breaking the
client's connection with the server. However, an alert message about the
invalid packet is sent to the error log, the affected client, and the server
console. The alert message contains the login name and the station address of
the affected client.

A two-part process between the client and the server determines the NCP Packet
Signature:

Γûá At LOGIN, the server and the client determine a shared, secret key known as
the session key.

Γûá For each request or response packet, the server and the client calculate a
signature based on the session key, a "fingerprint" algorithm, and the previous
packet's signature. The unique signature is appended to the NCP packet.

If NCP Packet Signature is installed correctly on the server and all of its
clients, it is virtually impossible to forge a valid NCP packet.

NoteThe Packet Burst loadable module, PBURST.NLM (NetWare 3.11 only), must be
loaded on NetWare servers in order for NCP Packet Signature to work. However,
using Packet Burst to transfer data between servers and clients is optional.

NCP Packet Signature Options

Because the packet signature process consumes CPU resources and slows
performance, both for the client and the NetWare server, NCP Packet Signature
is optional.

Several signature options are available, ranging from never signing NCP packets
to always signing NCP packets. Servers and clients both have four signature
levels that can be set.

The signature options for servers and clients combine to determine the level of
NCP Packet Signature on the network.

NoteSome combinations of server and client packet signature levels may slow
performance. However, low CPU-demand systems may not show any performance
degradation. Network supervisors can choose the packet signature level that
meets both their performance needs and their security requirements.

Server Levels

Server packet signature levels are assigned by a SET parameter. See Utilities
Reference for more information.

Client Levels

Packet signature levels at the workstation are assigned by using the following
NET.CFG option:

     netware requester
        signature level number

 Replace number with 0, 1, 2, or 3. The default is 1.

 NCP Packet Signature levels

 Number    Explanation

 0         Client does not sign packets (login fails if server is set to 3)

 1         Client signs packets only if the server requests it (server option
           is 2 or higher)

 2         Client signs packets if the server is capable of signing (server
           option is 1 or higher)

 3         Client signs packets and requires the server to sign packets (or
           login will fail)

 Effective Packet Signature Levels

 The packet signature levels for server and client interact to create the
 "effective" packet signature. Some combinations of server and client levels do
 not allow logging in.

 The table below shows the interactive relationship between the server packet
 signature levels and the client signature levels.

 Effective Packet Signature of Server and Client

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  ΓöéIf              Server=0        Server=1        Server=2        Server=3       Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéClient=0        No packet       No packet       No packet       No login       Γöé
  Γöé                signature       signature       signature                      Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéClient=1        No packet       No packet       Packet          Packet         Γöé
  Γöé                signature       signature       signature       signature      Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéClient=2        No packet       Packet          Packet          Packet         Γöé
  Γöé                signature       signature       signature       signature      Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéClient=3        No login        Packet          Packet          Packet         Γöé
  Γöé                                signature       signature       signature      Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 When to Use NCP Packet Signature

 NCP Packet Signature is not required for every installation. Some network
 supervisors may choose not to use NCP Packet Signature because they can
 tolerate certain security risks.

 You may not need to use NCP Packet Signature if

 Γûá Only executable programs reside on the server.

 Γûá All workstation users on the network are known and trusted by the
 supervisor.

 Γûá Data on the NetWare server is not sensitive; loss or corruption of this data
 will not impact operations.

 You may want to use NCP Packet Signature if

 Γûá An untrustworthy user uses a workstation on the network.

 Γûá Someone can easily access the network cabling system.

 Γûá There is an unattended, publicly accessible workstation on the network.

 The default NCP Packet Signature level is 1 for clients and 2 for servers. In
 general, this setting provides the most flexibility while still offering
 protection from forged packets. Below are some examples of using different
 signature levels.

 All Information on the Server Is Sensitive

 If an intruder gains access to any information on the NetWare server, it could
 damage the company.

 The network supervisor should set the server to level 3 and all clients to
 level 3 for maximum protection.

 Sensitive and Non Sensitive Information Reside on the Same Server

 The NetWare server has a directory for executable programs and a separate
 directory for corporate finances.

 The network supervisor should set the server to level 2 and the clients
 (including himself) that need access to corporate finances to level 3. All
 other clients remain at the default, level 1.

 Users Often Change Locations and Workstations

 The network supervisor is uncertain which employees will be using which
 workstations, and the server contains some sensitive data.

 The network supervisor should set the server to level 3. Clients should remain
 at the default, level 1.

 Workstation Is Publicly Accessible

 An unattended workstation is set up for public access to non-sensitive
 information, but another server on the network contains sensitive information.

 The network supervisor should set the sensitive server to level 3 and the
 unattended client to level 0.

 NCP Packet Signature Troubleshooting Tips

 This section describes some solutions to problems that may be associated with
 using NCP Packet Signature.

 Clients Are Not Signing Packets

 Make sure each OS/2 workstation has NetWare Client for OS/2 installed.

 Make sure that NCP Packet Signature is not turned off in the NET.CFG file.

 Clients Cannot Log In

 Make sure each workstation has NetWare Client for OS/2 installed.

 The following situations do not allow logging in:

 Γûá Server packet signature level=3, client packet signature level=0

 Γûá Server packet signature level=0, client packet signature level=3

 Γûá Utilities are old and do not support NCP Packet Signature

 Γûá The NetWare Client for OS/2 software is not version 2.1 and does not support
 NCP Packet Signature.

 "Error Receiving From the Network" Message

 The client is using an old LOGIN.EXE file that does not include NCP Packet
 Signature. Make sure the new LOGIN.EXE and other new utilities are installed
 in the \OS2 subdirectory on all servers on the network.

 Unsecure Clients Log In to Secure Server

 The clients are using an old LOGIN.EXE file that does not include NCP Packet
 Signature. Make sure the new LOGIN.EXE and other new utilities are installed
 in the \OS2 subdirectory on all servers. Add a preferred server statement to
 the NET.CFG file for all clients that have access to secure servers (level 3).


ΓòÉΓòÉΓòÉ 13. Using Token Ring Networks ΓòÉΓòÉΓòÉ

Using Token Ring Networks

Overview

If your token ring network includes IBM* source-routing bridges, your computers
use source routing to communicate across those bridges.

This chapter explains how to install and configure source routing on NetWare
servers and OS/2 workstations.

If your network requires source routing, install source-routing software on
both workstations and servers. Novell's source-routing software includes

Γûá ROUTE.NLM (for servers)

Γûá ROUTE.SYS (for OS/2 client workstations)

This software routes only IPX packets.

Other topics discussed include:

Installing Source-Routing on the Server

Installing Source-Routing on the Workstation

Configuring Source-Routing on the Workstation


ΓòÉΓòÉΓòÉ 13.1. Installing Source Routing on the Server ΓòÉΓòÉΓòÉ

Installing Source Routing on the Server

Procedure 1. At the server console, load ROUTE.NLM by typing

     LOAD ROUTE

     ROUTE.NLM is located in the SYS:SYSTEM directory. You can load it with
     command line parameters. You can also load ROUTE.NLM from a startup file.
     Utilities Reference explains more about the parameters.

 2. (Conditional) If you have two network boards in your server, load ROUTE.NLM
 again.

     Use the "board" parameter to specify a board number. For example, type

     LOAD ROUTE BOARD=02

     You can change a source-routing parameter after ROUTE is loaded. Type the
     LOAD ROUTE command followed by the parameter you want to change.


ΓòÉΓòÉΓòÉ 13.2. Installing Source Routing on the Workstation ΓòÉΓòÉΓòÉ

Installing Source Routing on the Workstation

Prerequisites

Checklist

 Install Netware Client for OS/2 with a TOKEN ODI driver.

 Understand source routing. (See the September 1990 Novell Application Notes.)

Procedure 1. Using a text editor, open the CONFIG.SYS file.

     For example, to use the OS/2 System Editor at an OS/2 command line, type

     E C:\CONFIG.SYS

     CONFIG.SYS is always located in the root of your boot drive.

 2. In the NetWare Client for OS/2 lines, find the line loading your TOKEN ODI
 driver.

     If you use Novell-supplied ODI drivers, the driver is called TOKEN.SYS.

 NoteIf use LANSUP.SYS and an NDIS driver, you do have an ODI driver loaded. In
 this case, find LANSUP.SYS.

 3. After the line that loads the TOKEN ODI driver, add a line to load the
 ROUTE.SYS driver.

     Specify the location of ROUTE.SYS. ROUTE.SYS is located where the other
     NetWare Client for OS/2 files are, usually in C:\NETWARE.

     For example, to load ROUTE.SYS from the default location, type

     DEVICE=C:\NETWARE\ROUTE.SYS

 4. Save and exit the CONFIG.SYS file.

 5. Use the OS/2 "Shutdown" feature to reboot your machine.


ΓòÉΓòÉΓòÉ 13.3. Configuring Source Routing on the Workstation ΓòÉΓòÉΓòÉ

Configuring Source Routing on the Workstation

Follow the procedures in this section to

Γûá Determine whether you need to configure source routing, and

Γûá Configure source routing, if needed.

Prerequisites

Checklist

 Install NetWare Client for OS/2.

 Install source routing on the server. See "Installing Source Routing on the
Server"

 Install source routing on the workstation.

 Understand source routing thoroughly. This section does not explain
source-routing terminology or how packets are routed. See related IBM
publications, such as IBM Token Ring Network Architecture Reference or the
September 1990 Novell Application Notes.

Procedures 1. Start the NetWare Client for OS/2 installation program.

     You can choose the "Installation" icon from the "Novell" group on your
     desktop.

 2. Choose "This workstation . . ." from the "Configuration" menu.

 3. Verify the location of NET.CFG and choose "Edit."

     The "Edit NET.CFG" window appears. You can cut and and paste text from the
     help window at the bottom of the screen to the "Current NET.CFG File
     Contents" window. Use the Key Definitions for the NET.CFG File chart.

 4. Select "Token-Ring source routing" from the "NET.CFG Options" box on the
 left of your screen.

 5. Determine whether to change the configuration for the "def", "gbr", "mbr",
 "nodes" and "board" settings under "Token-Ring source routing."

     5a. Select one of the five settings.

          Example: select "def".

     5b. Read the help window at the bottom of the screen to determine whether
     to change the configuration for the setting.

          You can choose the "Usage," "Description," and "Example" buttons on
          the right of the window for more information about the setting you've
          selected.

     5c.(Optional) To change the configuration, add the configuration lines (as
     shown in the "Usage" help window) in the "Current NET.CFG File Contents"
     box.

 Important You must follow the format requirements explained in the "Format of
 NET.CFG Options" topic. To see these requirements, select this topic from the
 "NET.CFG Options" box and choose "Usage".

 Repeat Steps 5a through 5c for each setting.

 6.Choose "Save."

 7.Exit the NetWare Client for OS/2 Installation program and use the OS/2
 "Shutdown" feature to restart your computer.


ΓòÉΓòÉΓòÉ 13.4. Key definitions for the NET.CFG file. ΓòÉΓòÉΓòÉ

Key definitions for the NET.CFG file

 To do this ...      Use these keys ...

 Highlight text      Click and drag with the mouse, or move the cursor with the
                     arrow keys while holding down the <Shift> key

 Copy text           <Ctrl><Insert>

 Cut text            <Shift><Delete> (text will reappear the next time you
                     refresh the window)

 Paste text          <Shift><Insert>

 Delete text         <Ctrl><Delete> (deleted text cannot be pasted)


ΓòÉΓòÉΓòÉ 14. Using Named Pipes ΓòÉΓòÉΓòÉ

Using Named Pipes

The following topics are discussed.

Installing Named Pipes for OS/2

Configuring Named Pipes for OS/2

Special Instructions for SQL Client Workstations


ΓòÉΓòÉΓòÉ 14.1. Installing Named Pipes for OS/2 ΓòÉΓòÉΓòÉ

You must install Named Pipes support on each computer that will use Named Pipes
on the network. In most cases, you must also set certain configuration options
for the protocol.

Named Pipes support between sessions on a single OS/2 client workstation is
provided by the OS/2 operating system.

However, if you need OS/2 sessions to communicate with other computers on the
network using Named Pipes, you must install remote Named Pipes support.

Prerequisite

 Install your Named Pipes distributed application. See the documentation for
your application.

Procedure

1. Start the NetWare Client for OS/2 Installation program.

     If NetWare Client for OS/2 is not installed, you can start the program
     from your WSOS2_1 diskette. Type INSTALL. You can install NetWare Client
     for OS/2 at the same time as you install Named Pipes.

     If NetWare Client for OS/2 is already installed, start the program by
     choosing "Installation" from the "Novell" group on your desktop.

 2. Choose "Requester on Workstation" from the "Installation" menu.

 3. Verify the target directory and source drive and choose "OK."

 4. Select an action from the "Requester Installation" screen based on whether
 NetWare Client for OS/2 is installed:

     4a. If NetWare Client for OS/2 is not installed, select "Edit CONFIG.SYS
     and Copy All Files . . . " and choose "OK."

     4b. If NetWare Client for OS/2 is already installed, select "Only Edit
     CONFIG.SYS . . ." and choose "OK."

 5. Select the ODI LAN driver for your network board and choose "Continue. . ."

 6. Select your preferences for NetWare support for DOS and MS Windows
 applications and choose "Continue . . ."

 7. Select "Remote Named Pipes Support."

 8. Set up your workstation as a Named Pipes client or server.

     8a. Choose "Client Support Only" to set up your workstation as a Named
     Pipes application client.

     If your workstation will be a client for the SQL Server distributed
     application, you must do some additional steps. After completing this
     section and "Configuring Named Pipes for OS/2", go to "Special
     Instructions for SQL Client Workstations".

     8b. Choose "Client and Server Support" and type a machine name to set up
     your workstation as a Named Pipes application server.

     Choose "Help" to see the syntax requirements for the machine name.

 9. Choose "Save . . ."

 10. Verify the filename and location and choose "OK."

     If you have not installed NetWare Client for OS/2, the "Copy Requester
     Files" screen appears. Continue with Step 11.

     If you have previously installed NetWare Client for OS/2, the main
     installation menu appears.

 11. Choose "Copy" and follow the screens to finish installing NetWare Client
 for OS/2.


ΓòÉΓòÉΓòÉ 14.2. Configuring Named Pipes for OS/2 ΓòÉΓòÉΓòÉ

Configuring Named Pipes for OS/2

Novell's Named Pipes support comes with default configuration settings. You may
want to customize the configuration. Follow the instructions below to

Γûá Determine whether you need to change the default configuration for Named
Pipes and SPX.

Γûá Change the configuration if necessary.

You can change the configuration for such features as

Γûá Available number of client and server sessions

Γûá Number of SPX sessions available for Named Pipes and other SPX communication
(Named Pipes uses SPX)

Prerequisite

 NetWare Client for OS/2 must be installed.

Procedure 1. Start the NetWare Client for OS/2 Installation program.

     The program might already be running if you just installed Named Pipes
     support. If the program is not running, choose the "Installation" icon
     from the "Novell" group on your desktop.

 2. Choose "This workstation . . ." from the "Configuration" menu.

 3. Verify the location of the NET.CFG file and choose "Edit."

     The "Edit NET.CFG" window appears. You can cut and and paste text from the
     help window at the bottom of the screen to the "Current NET.CFG File
     Contents" window. Use the Key Definitions for the NET.CFG File chart.

 4. Select "Named Pipes" from the "NET.CFG Options" box on the left of your
 screen.

 5. Determine whether to change the configuration for the "client sessions",
 "server sessions" and settings under "Named Pipes."

     If you decide not to change the configuration for a setting, no action is
     required for that setting.

     5a. Select one of the three settings.

          For example, select "client sessions."

     5b. Read the help window at the bottom of the screen to determine whether
     to change the configuration for the setting.

          You can choose the "Usage," "Description," and "Example" buttons on
          the right of your screen for more information about the setting
          you've selected.

     5c. (Optional) To change the configuration, add the configuration lines
     (as shown in the "Usage" help window) to the "Current NET.CFG File
     Contents" box.

 Important You must follow the format requirements explained in the "Format of
 NET.CFG Options" topic. To see these requirements, select this topic from the
 "NET.CFG Options" box and choose "Usage".

 Repeat Steps 5a through 5c for each setting.

 6. Select "Protocol Stack SPX" from the "NET.CFG Options" box on the left of
 your screen.

 7. Select the "sessions" setting under "Protocol Stack SPX."

 8. Read the help window at the bottom of the screen to determine whether to
 change the configuration for "sessions."

     You can choose the "Usage," "Description" and "Example" buttons on the
     right of your screen for more information about the setting you've
     selected.

 9. (Optional) To change the configuration, add the configuration lines (shown
 in the "Usage" help window) to the "Current NET.CFG File Contents" box.

     If you decide not to change the configuration, no action is required for
     this step.

 Important You must follow the format requirements explained in the "Format of
 NET.CFG Options" topic. To see these requirements, select this topic from the
 "NET.CFG Options" box and choose "Usage".

 10. Choose "Save."

 11. Exit the NetWare Client for OS/2 Installation program.

     11a. If your workstation will be a client for the SQL Server distributed
     application, close the installation program and go to "Special
     Instructions for SQL Client Workstations" Do not restart your computer
     yet.

     11b. If your workstation will not be an SQL client, close the installation
     program and use the OS/2 "Shutdown" feature to restart your computer.


ΓòÉΓòÉΓòÉ 14.3. Special Instructions for SQL Client Workstations ΓòÉΓòÉΓòÉ

Special Instructions for SQL Client Workstations

Important This is only for emulated DOS sessions.

OS/2 Client workstations for the SQL Server distributed application must use
special versions of the NETAPI.DLL and NETOEM.DLL files. These files are
contained in a \SQL directory on the WSOS2_1 diskette.

The \SQL NETAPI.DLL contains everything that the default NETAPI.DLL contains
(including the NETBIOS calls), as well as some additional function calls
required by SQL clients and servers.

Complete the following steps to copy these files to the correct location

Procedure 1. Insert the WSOS2_1 diskette into a floppy disk drive.

2. Copy the existing NETAPI.DLL loacated in the \NETWARE subdirectory to
NETAPI.BAK.

3. Create a \NETWARE\INSTALL$.NEW subdirectory.

4. Copy the NETAPI.DLL and NETOEM.DLL files from the \SQL subdirectory on the
diskette to the \NETWARE\INSTALL$.NEW subdirectory.

Warning Be sure to copy the files from the \SQL directory, since there is also
a NETAPI.DLL in the root directory on the diskette. The two NETAPI.DLL files
are not the same.

The \SQL NETAPI.DLL emulates certain features of LAN Manager support that are
required for SQL clients. However, this NETAPI.DLL does not provide full LAN
Manager support. An application that assumes full LAN Manager support if it
finds any LAN Manager calls may not run properly.

 5. Use the OS/2 "Shutdown" feature to restart your computer.


ΓòÉΓòÉΓòÉ 15. Using NetBIOS ΓòÉΓòÉΓòÉ

Using NetBIOS

The following topics are discussed in this section:

Determining Which NetBIOS Drivers to Set Up

Setting Up the Novell NetBIOS Driver

Configuring NETBIOS.OS2 with PROTOCOL.INI

Important The NetBIOS protocol was designed for small-scale networks. While
Novell has added functionality to the original specification, Novell's NetBIOS
emulation still works most effectively with small-scale networks. We recommend
that you use SPX instead of NetBIOS if your applications support SPX, your
network contains several thousand workstations, and your LAN segments are
interconnected with more than one router.

Overview

This chapter explains how to set up Novell's NetBIOS driver and how to
configure your workstation for NetBIOS when you also have IBM's Extended
Services or LAN Services NetBIOS installed.

NetWare Client for OS/2 provides a NetBIOS driver, NETBIOS.SYS, that emulates
the NetBIOS protocol.

The NetBIOS provided by Novell is called an emulator because it does not
transmit NetBIOS packets on the network. Instead, NetBIOS packets are
encapsulated in IPX packets, and the IPX packets are transmitted.

IBM Extended Services and LAN Services provide a native NetBIOS driver,
NETBEUI.OS2, rather than an emulation.


ΓòÉΓòÉΓòÉ 15.1. Determining Which NetBIOS Drivers to Set Up ΓòÉΓòÉΓòÉ

Determining Which NetBIOS Drivers to Set Up

When this section refers to the NetBIOS support available with an IBM product
(such as Extended Services), we assume the product includes the files we list.
By default, the files shown here are included in Extended Services and LAN
Services packages. By default, LAPS is included in both packages, although
different NetBIOS components are actually used in each package.

However, the files shown may also be included in other packages. For example,
you may have received the IBM LAPS program without receiving Extended Services.

In this case, you might have the NetBIOS support usually provided by Extended
Services without having the whole Extended Services product. Contact IBM to
resolve any questions about what IBM files you have relating to NetBIOS
support.

Use this section to determine whether your application needs access to the
Novell NETBIOS.SYS driver, the IBM NETBEUI.OS2 driver, or both.

The drivers your application can access depends on the following:

Γûá Whether you have Extended Services or LAN Services installed on your
workstation.

Γûá The interface used by your application.

Your Installed IBM Software

NetBIOS support is provided with:

Γûá Extended Services

Γûá LAN Services

Extended Services

Extended Services NetBIOS support is included in the LAPS programs.
NetBIOS-related pieces of LAPS are

Γûá NETAPI.DLL

Γûá ACSNETB.DLL

Γûá NETBIOS.OS2

Γûá NETBEUI.OS2

Γûá LANPDD

Γûá LANVDD

LAN Services

LAN Services NetBIOS support is included in the LAPS program and in
NETWKSTA.200.

Your Application's Interface

OS/2 NetBIOS applications use Dynamic Link Libraries (DLLs) to interface with
NetBIOS drivers. The DLL your application uses depends on the NetBIOS interface
standard your application follows:

Γûá ACSNETB.DLL

     This is IBM's NetBIOS 3.0 (NB30) interface introduced in OS/2 Version 2.0.
     Applications written before OS/2 Version 2.0 most likely cannot use it.

 Γûá The NETAPI.DLL

     This is the original OS/2 NetBIOS Submit interface, supported by LAN
     Manager and LAN Server before OS/2 Version 2.0 was released.

 You can run applications that use different interfaces at the same time, as
 long as you have the support for each interface installed and configured. For
 example, you can run an NB30 application and a NetBIOS Submit application on
 the same workstation.

 Refer to the documentation for your application to determine which NetBIOS
 interface it uses; then follow the flowcharts below to see

     Γûá Whether the IBM or Novell NetBIOS driver can be accessed by your
     application.

     Γûá Where to find instructions on setting up the drivers.

     Chart Determine What NetBIOS Support You Have for NetBIOS 3.0 (NB30)
     applications

     Chart Determine What NetBIOS Support You Have for NetBIOS Submit
     Applications


ΓòÉΓòÉΓòÉ 15.1.1. Determine what NetBIOS support you have for NetBIOS 3.0 ΓòÉΓòÉΓòÉ

(NB30) applications Determine what NetBIOS support you have for NetBIOS 3.0
(NB30) applications


ΓòÉΓòÉΓòÉ 15.1.2. Determine What NetBIOS Support You Have for NetBIOS Submit ΓòÉΓòÉΓòÉ

Applications Determine What NetBIOS Support You Have for NetBIOS Submit
Applications


ΓòÉΓòÉΓòÉ 15.2. Setting Up the Novell NetBIOS Driver ΓòÉΓòÉΓòÉ

Setting Up the Novell NetBIOS Driver

Do this section only if you were directed here from the flow chart Determine
What NetBIOS Support You Have for NetBIOS Submit Applications because you

Γûá Have a NetBIOS Submit application

Γûá Have Extended Services

Γûá Do not have LAN Services

As the figure below shows, the Novell NetBIOS driver interfaces with Novell's
NETAPI.DLL file when you do not have Extended Services.

NetBIOS Requests through Novell's NetBIOS Driver

As the figure shows, if you use Extended Services, the NETAPI.DLL is the one
from the Extended Services package. This NETAPI.DLL interfaces with a
NETSUB.DLL file from Novell, which in turn works with the Novell NetBIOS
driver.

NetBIOS Requests through Novell's NetBIOS Driver with Extended Services
Installed

Follow the procedures in "Installing the Driver" to use the Novell NetBIOS
driver. The procedures apply whether or not you have Extended Services.

Important If you use Extended Services, you must get an updated NETAPI.DLL file
from IBM. The one shipped with base Extended Services 1.0 does not provide the
intended NetBIOS support.


ΓòÉΓòÉΓòÉ 15.2.1. Installing the Driver ΓòÉΓòÉΓòÉ

Installing the Driver

Prerequisites

 Install Extended Services if you have it. See the IBM documentation for
Extended Services.

 Install your NetBIOS application. See the documentation for your application.

NoteYou can install NetWare Client for OS/2 from this procedure.

You must install the Novell NetBIOS driver on each computer that will use
Novell NetBIOS.

Procedure 1. Start the NetWare Client for OS/2 Installation program.

     If NetWare Client for OS/2 is not installed, start the program from your
     WSOS2_1 diskette. Type INSTALL. You can install NetWare Client for OS/2
     when you install NetBIOS.

     If NetWare Client for OS/2 is installed, start the program by choosing
     "Installation" from the "Novell" group on your desktop.

 2. Choose "Requester on Workstation" from the "Installation" menu.

 3. Verify the target and source directory and choose "OK."

 4. Select an action from the "Requester Installation" screen based on whether
 NetWare Client for OS/2 is installed

     4a. If NetWare Client for OS/2 is not installed, select "Edit CONFIG.SYS
     and Copy All Files . . . " and choose "OK."

     4b. If NetWare Client for OS/2 is installed, select "Only Edit CONFIG.SYS
     . . ." and choose "OK."

 5. Select the ODI driver for your network board and choose "Continue. . ."

 6. Select your preferences for NetWare support for DOS and Windows
 applications and choose "Continue . . ."

 7. Select "NetBIOS Emulation for OS/2 Sessions."

 8. Choose "Save . . ."

 9. Verify the filename and location and choose "OK."

     If you have not previously installed NetWare Client for OS/2, the "Copy
     Requester Files" screen appears. Continue with Step 10.

     If you have previously installed NetWare Client for OS/2, the main
     installation menu appears. Go to "Configuring the Driver" below.

 10. Choose "Copy" and follow the screens to finish installing NetWare Client
 for OS/2.

     When the main menu returns, go to "Configuring the Driver" below.

 Configuring the Driver

 Novell's NetBIOS driver comes with default configuration settings. You may
 want to customize the configuration. Follow the instructions below to

 Γûá Determine whether you need to change the default configuration for NetWare
 NetBIOS.

 Γûá Change the configuration if necessary.

 You can change the configuration to manage such features as names, sessions,
 and commands.

 If you do not know what NetBIOS names, sessions, and commands are, see the
 documentation for your NetBIOS application.

 Prerequisite

  NetWare Client for OS/2 must be installed.

 Procedure 1. Start the NetWare Client for OS/2 Installation program.

     The program may already be running if you just installed the NetBIOS
     driver.

     If it isn't running, start it by choosing the "Installation" icon from the
     "Novell" group on your desktop.

 2. Choose "This workstation . . ." from the "Configuration" menu.

 3. Verify the location of NET.CFG and choose "Edit."

     The "Edit NET.CFG" window appears. You can cut and and paste text from the
     help window at the bottom of the screen to the "Current NET.CFG File
     Contents" window. Use the Key Definitions for the NET.CFG File chart.

 4. Select "NetWare NetBIOS" from the "NET.CFG Options" box on the left of your
 screen.

 5. Determine whether to change the configuration for the settings under
 "NetWare NetBIOS."

     If you decide not to change the configuration for a setting, no action is
     required for that setting.

     5a. Select one of the settings.

          For example, select "abort timeout."

     5b. Read the help window at the bottom of the screen to determine whether
     to change the configuration for the setting.

          You can choose the "Usage," "Description," and "Example" buttons on
          the right of your screen to see more information about the setting
          you've selected.

     5c. (Optional) To change the configuration, add the configuration lines
     (as shown in the "Usage" help window) into the "Current NET.CFG File
     Contents" box.

 Important You must follow the format requirements explained in the "Format of
 NET.CFG Options" topic. To see these requirements, select this topic from the
 "NET.CFG Options" box and choose "Usage".

 Repeat steps 5a through 5c for each setting.

 6. Choose "Save."

 7. Exit the NetWare Client for OS/2 Installation program.

     If your NetBIOS application will not access the IBM NetBIOS driver, use
     the OS/2 "Shutdown" feature to reboot your computer.

     If your NetBIOS application will access the IBM NetBIOS driver, do not
     reboot. Instead, configure the IBM driver as instructed in one of the
     following sections :

     Γûá "Configuring NETBIOS.OS2 with PROTOCOL.INI"

     Γûá "Configuring NETWKSTA.200 with IBMLAN.INI" in the "Configuring
     NETBIOS.OS2 with PROTOCOL.INI" section

     If you do not know which of these two sections to read, go to "Determining
     Which NetBIOS Drivers to Set Up."


ΓòÉΓòÉΓòÉ 15.3. Configuring NETBIOS.OS2 with PROTOCOL.INI ΓòÉΓòÉΓòÉ

Do this section only if you were directed here from the flow chart in the
figure Determine What NetBIOS Support You Have for NetBIOS 3.0 (NB30)
Applications because you

Γûá Have the LAPS program.

Γûá Have a NetBIOS 3.0 application.

As the figure below shows, IBM's ACSNETB.DLL interfaces with NETBIOS.OS2, also
provided by IBM. NETBIOS.OS2 can be configured to pass NetBIOS requests to
either of the following:

Γûá NETBEUI.OS2, IBM's NetBIOS driver.

Γûá NETBIOS.SYS, Novell's NetBIOS driver.

This section explains how to configure NETBIOS.OS2 to support both NetBIOS
drivers simultaneously or to support only Novell's driver.

If you only want to use IBM's NetBIOS driver, you do not need to configure. By
default, NETBIOS.OS2 communicates only to NETBEUI.OS2.

NetBIOS Requests through NETBIOS.OS2

Prerequisites

Checklist  Install Extended Services with NetBIOS support. Verify that you can
get a NetBIOS connection.

 Install LAN Services (NetBIOS support is installed by default). Verify that
you can get a LAN connection.

 Install NetWare Client for OS/2 with the Novell NetBIOS driver.

In this procedure, you edit the PROTOCOL.INI file to define a virtual adapter
for the Novell and IBM NetBIOS drivers.

Procedure In this procedure, you edit the PROTOCOL.INI file to define a virtual
adapter for the Novell and IBM NetBIOS drivers.

1. Open the PROTOCOL.INI file in a text editor.

     PROTOCOL.INI is located in the \IBMCOM directory.

     For example, to use the OS/2 System Editor at the command line, type:

     E C:\IBMCOM\PROTOCOL.INI <Enter>

 2. Find the following line:

     [NETBIOS]

     If the [NETBIOS] line does not exist, type the line at the end of the
     PROTOCOL.INI file, exactly as shown.

 3. On a new line under [NETBIOS], type the following line:

     DriverName = NETBIOS$

     The line must be indented at least one space and must follow other
     formatting requirements for IBMLAN.INI. NETBIOS$ is the device name of
     NETBIOS.OS2.

     If the line already exists, go to the next step.

 4. On a new line under the DriverName line, type lines assigning adapter
 numbers to the IBM and Novell NetBIOS drivers.

     To allow NB30 NetBIOS applications to use only Novell's NetBIOS driver,
     add a line for Novell's NetBIOS.

     To allow NB30 applications to use both Novell and IBM drivers, add another
     line for IBM's NetBIOS.

 NoteWhen you define the Novell NetBIOS network, your default definition for
 the IBM NetBIOS network is no longer defined. So, if you are going to use IBM
 NetBIOS driver, you must add a line for the IBM network.

     Each line you add should look similar to the following:

     ADAPTERa = b,c,sessions,commands,names

     NoteIf you have existing ADAPTER lines, leave them.

     Replace the variables in the line with values shown in the Paremeters for
     Defining NetBIOS in PROTOCOL.INI chart.

     For example, to enable applications to use both the Novell or the IBM
     NetBIOS driver, the lines in your PROTOCOL.INI file might read:

     [NETBIOS]
          DriverName = NETBIOS$
          Adapter0 = ipxnb$,0,16,16,8
          Adapter1 = netbeui$,0,32,14,8

     For more information about defining adapters in NETBIOS.OS2, see your
     Extended Services documentation.

 5. Insert a blank line at the end of the file.

 6. Save the PROTOCOL.INI file and exit your text editor.

 7. Use the "Shutdown" feature from the OS/2 system menu to reboot your
 computer.

     When your computer restarts, your NB30 NetBIOS applications can use each
     driver you defined with an adapter line.

 Configuring NETWKSTA.200 with IBMLAN.INI

 Do this section only if you were directed here from the flow chart Determine
 What NetBIOS Support You Have for NetBIOS Submit Applications because you:

 Γûá Have a NetBIOS Submit application.

 Γûá Have LAN Services.

 As the figure below shows, NETAPI.DLL interfaces with IBM's NETWKSTA.200. The
 NETAPI.DLL file used is the one provided with LAN Services. This happens by
 default, since the \MUGLIB\DLL directory that stores the LAN Services
 NETAPI.DLL comes earlier in the path than the \NETWARE directory that contains
 the NetWare Client for OS/2 NETAPI.DLL.

 NetBIOS Requests through NETWKSTA.200

 NETWKSTA.200 can be configured to pass NetBIOS requests to either

 Γûá NETBEUI.OS2, IBM's NetBIOS driver.

 Γûá NETBIOS.SYS, Novell's NetBIOS driver.

 This section explains how to configure NETWKSTA.200 to support both NetBIOS
 drivers simultaneously or to support only Novell's driver.

 If you only want to use IBM's NetBIOS driver, you do not need to configure. By
 default, NETWKSTA.200 talks only to NETBEUI.OS2.

 Prerequisites

 Checklist  Install Extended Services if you have it.

  Install LAN Services (NetBIOS support is installed by default). Verify that
 you can get a LAN connection.

  Install NetWare Client for OS/2 with the Novell NetBIOS driver.

 Procedure 1.Open the IBMLAN.INI file in a text editor.

     IBMLAN.INI is located in the \IBMLAN directory on your boot drive.

     For example, to use the OS/2 System Editor at the command line, type

     E C:\IBMLAN\IBMLAN.INI <Enter>

 2. Find the following line:

     [networks]

     Underneath the [networks] line, you should see a line, similar to the
     following, that defines a particular network as the one using IBM's
     NetBIOS driver, NETBEUI.OS2:

     net1 = NETBEUI$,1,LM10,32,50,14

     In this case, the line defines net1 as the network using the IBM NetBIOS
     driver.

 3. If the IBM driver is defined to net1, change the 1 to a 2.

     The line should be similar to the following:

     net2 = NETBEUI$,1,LM10,32,50,14

     You must change the IBM driver because the Novell driver must be defined
     to net1 for dual NetBIOS to work.

 4. Underneath any existing net statements, type a line assigning network
 number 1 to the Novell NetBIOS driver.

 NoteA network for IBM NetBIOS is defined by default in both LAN Requester and
 LAN Server. If you want NetBIOS Submit applications to only use Novell's
 NetBIOS driver, comment out the line for the IBM driver with a semicolon.

     The line must be indented at least one space and must follow other
     formatting requirements for IBMLAN.INI.

     The Novell line you add should look similar to the following

     neta = b,c,LM10,sessions,commands,names

     Replace the variables in the line with values shown in the Parameters for
     Defining Dual NetBIOS in IBMLAN.INI table:

     For example, to enable applications to use both the Novell and the IBM
     NetBIOS drivers, the lines in your IBMLAN.INI file might read:

     [networks]
          net1 = IPXNB$,1,LM10,32,16,8
          net2 = NETBEUI$,1,LM10,16,16,8

     For more information about defining networks for NETWKSTA.200, see your
     LAN Services documentation.

 5. If your computer is a LAN Server, do the following:

     5a. Find the [server] line in your IBMLAN.INI file.

     5b. At the end of the [server] section, find the following line:

          srvnets = neta

     5c. Add the Novell NetBIOS network to the line.

          Separate the Novell net from any existing nets with a comma.

          For example, if Novell's NetBIOS driver was net2:

          srvnets = NET1,NET2

          The line must be indented at least one space and must follow other
          formatting requirements for IBMLAN.INI.

          This line tells LAN Services the network to send NetBIOS calls for
          servers on.

 6. If your computer is a LAN Requester, do the following:

     6a. Find the [requester] line in your IBMLAN.INI file.

     6b.  At the end of the [requester] section, find the following line:

          wrknets = neta

     6c. Add the Novell NetBIOS network to the line.

          Separate the Novell net from any existing nets with a comma.

          For example:

          wrknets = NET1,NET2

          The line must be indented at least one space and must follow other
          formatting requirements for IBMLAN.INI.

          This line tells LAN Services what network to send NetBIOS calls for
          workstations on.

 7. Save the IBMLAN.INI file and exit your text editor.

 8. Use the "Shutdown" feature from the OS/2 system menu to reboot your
 computer.

     When your computer restarts, your NetBIOS Submit applications can use both
     the Novell and the IBM NetBIOS drivers.

 NoteNETWKSTA.200 must be started before any kind of NetBIOS connection will
 work. You can start it automatically on startup or with the LAN Services
 NETSTART command at a command line. See your LAN Services documentation.


ΓòÉΓòÉΓòÉ 15.3.1. Parameters for Defining NetBIOS in PROTOCOL.INI ΓòÉΓòÉΓòÉ

Paremeters for Defining NetBIOS in PROTOCOL.INI

This chart has the format:

Variable

          Meaning of variable

 ADAPTER

          Adapter is a key word for NETBIOS.OS2. It is not case-sensitive.

 a

          Replace "a" with a number from 0 to 3. This is the adapter number
          used by the application.

          When specifying an adapter number:

               Γûá Do not use the same number used in any other adapter
               statements. Each adapter number can only be defined to one
               NetBIOS driver.

               Γûá Do not skip adapter numbers. For example, if you have an
               adapter statement that uses ADAPTER0, use ADAPTER1 for your next
               adapter statement.

 b

          Replace "b" with the device name for the NetBIOS driver. NETBIOS.OS2
          recognizes this name when determining which driver to pass NetBIOS
          calls to.

               Γûá Replace "b" with IPXNB$ for the Novell NetBIOS driver.

               Γûá Replace "b" with NETBEUI$ for the IBM NetBIOS driver.

 c

          Replace "c" with a number from 0 to 3. This number is the virtual
          adapter number used by the target NetBIOS driver.

               Γûá For Novell's NetBIOS driver, always specify 0.

               Γûá For IBM's NetBIOS driver, specify whichever virtual adapter
               you want used. See the Extended Services documentation on
               NETBEUI.OS2.

 sessions

          Replace "sessions" with the number of NetBIOS sessions you want
          allocated to NetBIOS 3.0 applications. This number specifies the
          maximum number of sessions that can be active between NETBIOS.OS2 and
          Novell's NetBIOS driver.

          Novell's NetBIOS driver is configured by the sessions setting in the
          NET.CFG. The number of sessions allocated to the application is
          either the NET.CFG value or the value on this line of the
          PROTOCOL.INI, whichever is lowest.

          For example, if you set 64 sessions in NET.CFG, and the value on this
          line is only 48, NetBIOS 3.0 applications can only use 48 sessions.

          However, if you set 30 sessions in NET.CFG and the value on this line
          is 50, NetBIOS 3.0 applications can use 30 sessions.

 commands

          Replace commands with the number of NetBIOS commands you want
          allocated to the NB30 NetBIOS application. This number specifies the
          maximum number of commands that can be active between NETBIOS.OS2 and
          Novell's NetBIOS driver.

          Novell's NetBIOS driver is configured by the commands setting in
          NET.CFG. The number of commands actually allocated to the application
          is either the NET.CFG value or the value on this line of
          PROTOCOL.INI, whichever is lowest.

          For example, if you set 128 commands in NET.CFG, and the value on
          this line is only 100, the application can only use 100 commands.

          If you set 80 commands in NET.CFG and the value on this line is 95,
          the application can only use 80 commands.

 names

          Replace names with the number of NetBIOS names you want allocated to
          the NB30 application. This number specifies the maximum number of
          names that can be active between NETBIOS.OS2 and Novell's NetBIOS
          driver.

          Novell's NetBIOS driver is configured by the names setting NET.CFG.
          The number of names allocated to the application is either the
          NET.CFG value or the value on this line PROTOCOL.INI, whichever is
          lowest.

          For example, if you set 128 names in NET.CFG, and the value on this
          line is only 100, the application can only use 100 names.

          However, if you set 80 names in NET.CFG and the value on this line is
          95, the application can only to use 80 names.


ΓòÉΓòÉΓòÉ 15.3.2. Parameters for Defining Dual NetBIOS in IBMLAN.INI ΓòÉΓòÉΓòÉ

Parameters for Defining Dual NetBIOS in IBMLAN.INI

Variable

          Meaning of variable

 NET

          NET is a standard key word for NETWKSTA.200. It is not
          case-sensitive.

 a

          Replace "a" with a number from 1 to 4. This is the number of the
          network you want NETBIOS.OS2 to use when sending NetBIOS requests to
          a NETBIOS driver. Each NetBIOS driver must have its own network
          number.

          When specifying a network number:

               Γûá Use 1 for the Novell NetBIOS driver and 2 for the IBM NetBIOS
               driver.

               Γûá Do not use the same number that is used in any other net
               statements. Each network number can only be defined to one
               NetBIOS driver.

               Γûá Do not skip numbers. For example, if you have a net statement
               that uses NET1, use NET2 for your next statement.

 b

          Replace "b" with the device name for the NetBIOS driver. NETWKSTA.200
          recognizes this name when determining which driver to pass NetBIOS
          calls to.

          Replace "b" with IPXNB$ for the Novell NetBIOS driver.

          (NETBEUI$ is the device name for the IBM NetBIOS driver.)

 LM10

          LM10 is the name of the protocol that enables NETWKSTA.200 to
          communicate with more than one NetBIOS driver. Type it exactly as it
          appears.

 c

          Replace "c" with a number from 0 to 3. This number is the virtual
          adapter number used by the target NetBIOS driver to receive NetBIOS
          requests from NETWKSTA.200.

               Γûá For Novell's NetBIOS driver, always specify 0.

               Γûá For IBM's NetBIOS driver, specify whichever virtual adapter
               you want used. See the Extended Services documentation on
               NETBEUI.OS2.

 sessions

          Replace "sessions" with the number of NetBIOS sessions you want
          allocated to the NetBIOS Submit application. This number specifies
          the maximum number of sessions that can be active between
          NETWKSTA.200 and Novell's NetBIOS driver.

          Novell's NetBIOS driver is configured with the sessions setting in
          the NET.CFG file. The number of sessions allocated to the application
          is either the NET.CFG value or the value on this line of the
          IBMLAN.INI, whichever is lowest.

          For example, if you set 64 sessions in NET.CFG, and the value on this
          line is only 48, the application can only use 48 sessions.

          However, if you set 30 sessions in NET.CFG and the value on this line
          is 50, the application can only be use 30 sessions.

 commands

          Replace "commands" with the number of NetBIOS commands you want
          allocated to the NetBIOS Submit application. This number specifies
          the maximum number of commands that can be active between
          NETWKSTA.200 and Novell's NetBIOS driver.

          Novell's NetBIOS driver is configured with the names setting NET.CFG.
          The number of names actually allocated to the application is either
          the NET.CFG value or the value on this line of the IBMLAN.INI,
          whichever is lowest.

          For example, if you set 128 commands in NET.CFG, and the value on
          this line is only 100, the application can only to use 100 commands.

          If you set 80 commands in NET.CFG and the value on this line is 95,
          the application will only be able to use 80 commands.

 names

          Replace names with the number of NetBIOS names you want allocated to
          the NetBIOS Submit application. This number specifies the maximum
          number of names that can be active between NETWKSTA.200 and Novell's
          NetBIOS driver.

          Novell's NetBIOS driver is configured with the names setting in
          NET.CFG. The number of names actually allocated to the application is
          either the NET.CFG value or the value on this line of the IBMLAN.INI,
          whichever is lowest.

          For example, if you set 128 names in NET.CFG, and the value on this
          line is only 100, the application can only use 100 names.

          However, if you set 80 names in NET.CFG and the value on this line is
          95, the application will only be able to use 80 names.


ΓòÉΓòÉΓòÉ 16. Using ODINSUP and LANSUP ΓòÉΓòÉΓòÉ

Using ODINSUP and LANSUP

This section discusses:

How Board Sharing Is Possible

Setting Up ODINSUP

Setting Up LANSUP

Use this chapter if you want NetWare Client for OS/2 to share a network board
with one or more of the following IBM software products:

 Γûá Extended Services
 Γûá LAN Server
 Γûá LAN Requester

 NoteIf you have Extended Services or LAN Services, you may also want to set up
 the NetBIOS protocol. After doing the steps in this chapter, you can see
 "Using NetBIOS".


ΓòÉΓòÉΓòÉ 16.1. How Board Sharing Is Possible ΓòÉΓòÉΓòÉ

How Board Sharing Is Possible

NetWare Client for OS/2 uses protocol drivers and network drivers written to
the ODI (Open Data-Link Interface) specification.

Extended Services and LAN Services use protocol drivers and network drivers
written to the NDIS specification.

Even though NetWare Client for OS/2 uses a different driver specification than
Extended Services and LAN Services, NetWare Client for OS/2 can still share a
network board with these products. This is possible because of two drivers that
Novell provides:

Γûá ODINSUP,

     Which lets Extended Services and LAN Services use ODI LAN drivers. Use
     ODINSUP when you want the ODI network driver to control the board. See
     Setting Up ODINSUP.

 Γûá LANSUP,

     Which lets NetWare Client for OS/2 use NDIS network drivers. Use LANSUP
     when you want the NDIS driver to control the board. See Setting Up LANSUP.


ΓòÉΓòÉΓòÉ 16.2. Setting Up ODINSUP ΓòÉΓòÉΓòÉ

Setting Up ODINSUP

NoteExcept where noted, the instructions in this section apply whether you have
Extended Services, LAN Services, or both. However, the sample configuration
files differ depending on the IBM software you have. Be sure to refer to the
correct sample files for your environment.

ODINSUP installation can be done automatically using the "Utilities" option of
the OS/2 Workstation Installation program, or by modifying the configuration
files with a text editor.

The sections listed below discuss how to set up each of the three parts using a
text editor. Each part sets up a different configuration file. You must
complete all three parts.

 Part A: Binding ODI Drivers in PROTOCOL.INI
 Part B: Loading ODINSUP in CONFIG.SYS
 Part C: Configuring ODINSUP in NET.CFG
 Sample Configuration Files for ODINSUP

 ODINSUP supports Ethernet- and token ring-compatible ODI drivers. It does not
 support ARCnet or PC Network II drivers.


ΓòÉΓòÉΓòÉ 16.2.1. Part A: Binding ODI Drivers in PROTOCOL.INI ΓòÉΓòÉΓòÉ

Part A: Binding ODI Drivers in PROTOCOL.INI

In this section, you edit the PROTOCOL.INI file in a text editor to do the
following:

Γûá Bind the NDIS protocol stack to the ODI drivers

Γûá Remove the line binding the NDIS protocol stack to the NDIS MAC drivers

NoteThese instructions are for LAN Server and LAN Requester 2.x.

Prerequisites

Checklist

 Install Extended Services on the workstation. If you have an NDIS driver for
the network board in your computer, verify that you can get a Communications
Manager or Database Manager connection. See the documentation for Extended
Services.

 Install LAN Server or LAN Requester on the workstation. If you have an NDIS
driver for the network board in your computer, verify that you can get
connections properly on your LAN Server network. See the documentation for LAN
Services.

 After installing all IBM software, install NetWare Client for OS/2. Using the
ODI driver for the board, verify that you can get connections properly on your
NetWare network.

NoteOnce you install NetWare Client for OS/2, Extended Services and LAN
Services will not be able to use the network board to make connections until
you have completely set up ODINSUP as instructed in this chapter.

Procedure 1. Open the PROTOCOL.INI file in a text editor.

     PROTOCOL.INI is located in the \IBMCOM directory on your boot drive.

     For example, to use the OS/2 System Editor at the command line, type

     E C:\IBMCOM\PROTOCOL.INI

 2. Find all occurrences of the lines that bind the NDIS MAC drivers.

     You can search for Bindings = NDIS MAC driver.

     If you don't know the name of the NDIS driver to look for, see your
     Extended Services or LAN Services documentation.

     For example, to search for a token ring NDIS driver, find the following
     line:

     Bindings = IBMTOK_NIF

     Bindings lines may be in either of the following sections, depending on
     whether you have Extended Services or LAN Services installed:

     [NETBEUI_nif]
     [LANDD_nif]

 3. Use a semicolon to comment out all Bindings lines found in Step2.

     For example, your PROTOCOL.INI for a token ring driver might look like the
     following:

     [LANDD_nif]
     .
     .
     ; Bindings = IBMTOK_NIF

 4. After each commented-out Bindings line, add a line to bind the NDIS
 protocol to an ODI driver.

     Follow the same syntax as the line you commented out, using the ODI driver
     name instead of the NDIS driver name.

     For example, to add a line for the TOKEN.SYS ODI driver:

     [LANDD_nif]
     .
     .
     ; Bindings = IBMTOK_NIF
     Bindings = TOKEN

 Since driver names in the PROTOCOL.INI file cannot start with a number, place
 an X before 3Com drivers and other drivers that start with a number (Example:
 Bindings = X3C503).

 Suggestion If you do not know which ODI driver name to use, you can restart
 your machine. An error message will appear, displaying the name of the ODI
 driver that should be used. If you do this, reopen the PROTOCOL.INI file and
 return to this step of the procedure.

 5. (Conditional) Type an instance number to bind the NDIS protocol to a
 particular occurrence of a board.

     If you have two or more network boards using the same ODI driver, the NDIS
     protocol uses the first network board of that type.

     To have NDIS use a board other than the first one found, you can specify
     an instance number. Type the instance number at the end of the driver
     name, with no space between the driver name and the instance number.

     For example, if you have two token ring network boards, have NDIS use the
     second board by typing an instance number for the second board, as shown:

     [LANDD_nif]
     .
     .
     ; Bindings = IBMTOK_NIF
     Bindings = TOKEN2

 6. (Conditional) Bind the NDIS protocol to additional ODI drivers.

     To bind the NDIS protocol to more than one ODI driver, type both driver
     names on the same line, separated by a comma.

     For example, to bind to both an NE2000 driver and an NE1000 driver, type:

     Bindings=ne2000,ne1000

 7. Add an empty header for the ODI drivers.

     7a. Locate the MAC SECTION of the PROTOCOL.INI file.

          You can search for MAC SECTION.

     7b. At the end of the MAC section, type a header for each ODI driver you
     specified in a Bindings line in Steps 4 through 6.

          Use the ODI driver name. For example, for a token ring ODI driver,
          type the following line:

          [TOKEN]

          Put a blank line before and after the header section. If the driver
          name starts with a number, you do not need an X in front of the
          number for this step.

          This ODI driver header is a place holder so that if you configure
          with the LAPS program in the future, the Bindings information will
          not be erased.

 8. Save and exit the PROTOCOL.INI file.

     Do not exit the text editor. Go to "Part B: Loading ODINSUP in CONFIG.SYS"


ΓòÉΓòÉΓòÉ 16.2.2. Part B: Loading ODINSUP in CONFIG.SYS ΓòÉΓòÉΓòÉ

Part B: Loading ODINSUP in CONFIG.SYS

In this section, you edit the CONFIG.SYS file in a text editor to do the
following:

Γûá Load the ODINSUP driver

Γûá Prevent the NDIS network driver (MAC) from loading

Prerequisite

 Follow the instructions in "Part A: Binding ODI Drivers in PROTOCOL.INI"

Procedure 1. Open the CONFIG.SYS file in a text editor.

     CONFIG.SYS is located at the root of your boot drive.

 2. Find the lines that load the NDIS MAC drivers.

     For example, for a token driver, search for the following line:

     DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2

     If you don't know the name of your NDIS driver, see your Extended Services
     or LAN Services documentation.

 3. Comment out the NDIS MAC driver that is equivalent to the ODI driver you
 are using.

     For example, to comment out a token ring NDIS MAC driver, place a REM
     command in front of the line that loads it, as shown:

     REM DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2

     If you have network boards and NDIS drivers for other communications
     software, do not comment out the lines to load those drivers.

 4. In NetWare Client for OS/2 lines, find the line loading the ODI driver.

 5. On a new line underneath the ODI driver, insert a line to load the ODINSUP
 protocol.

     ODINSUP is located in the directory where you installed the NetWare Client
     for OS/2 files (\NETWARE by default).

     For example, to load the ODINSUP protocol from the default location, type:

     DEVICE=C:\NETWARE\ODINSUP.SYS

 NoteIf you have the Source-Routing driver, ROUTE.SYS, loaded after the ODI
 driver, put the ODINSUP line after the ROUTE.SYS line.

 6. Verify that your file meets the load order requirements shown in the table
 below.

     By default, these load order requirements will be met.

     If you have rearranged your CONFIG.SYS, it may violate the load order
     requirements.

 Load Order Requirements for ODINSUP CONFIG.SYS File

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  ΓöéThese components . . .        ΓöéMust load before these        Γöé
  Γöé                              Γöécomponents . . .              Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéPROTMAN.OS2 (in OS/2 section  ΓöéThe ODINSUP protocol          Γöé
  Γöéright after path statements)  Γöé                              Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéLSL.SYS (in NetWare Client forΓöéThe ODI driver The ODINSUP    Γöé
  ΓöéOS/2 section)                 Γöéprotocol                      Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéThe ODI driver (in NetWare    ΓöéThe ODINSUP protocol          Γöé
  ΓöéClient for OS/2 section)      Γöé                              Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéNWIFS.IFS (in NetWare Client  ΓöéNETWKSTA.200 (only in LAN     Γöé
  Γöéfor OS/2 section)             ΓöéServices configurations)      Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

     6a. If your file meets load order requirements, go to Step 8.

     6b. If your file violates load order requirements, go to Step 7.

 7. Rearrange your CONFIG.SYS file to meet load order requirements for ODINSUP.

     We suggest you make your file match the sample file shown for your
     environment. See "Sample Configuration Files for ODINSUP" for a list of
     sample configuration files.

     After rearranging your CONFIG.SYS file, go on to Step 8.

 8. Save and exit the CONFIG.SYS file.

 Do not exit the text editor. Go to "Part C: Configuring ODINSUP in NET.CFG"


ΓòÉΓòÉΓòÉ 16.2.3. Part C: Configuring ODINSUP in NET.CFG ΓòÉΓòÉΓòÉ

Part C: Configuring ODINSUP in NET.CFG

Important A NET.CFG file is required to use ODINSUP.

In this section, you edit or create a NET.CFG that does the following:

Γûá Enables frame types for ODINSUP.

Γûá Specifies to ODINSUP the node address known by Extended Services and the
format in which that address is transmitted.

Γûá Binds ODINSUP to an ODI driver or drivers.

Γûá Increases the size of the packet that can be transmitted through the Link
Support Layer program (if necessary).

Prerequisites

Checklist  Follow the instructions in "Part A: Binding ODI Drivers in
PROTOCOL.INI"

 Follow the instructions in "Part B: Loading ODINSUP in CONFIG.SYS"

Procedure 1. Open the NET.CFG text file in the text editor.

     NET.CFG is located in the root of your boot drive. If NET.CFG does not
     exist, create a new file with that name.

 2. Enable frame types for ODINSUP.

     2a. Type the following line at the top of the file:

          link driver drivername

          Replace drivername with the name of your ODI driver. For example, for
          a token ring driver, type:

          link driver token

     2b. Under the Link Driver line, type the lines to enable frame types.

          Enable all frame types supported by the board.

          Use the frame setting to do this.

          For example, to enable all frame types for token ring, type the
          following:

          link driver token
               frame token-ring
               frame token-ring_snap

          To enable all frame types for Ethernet, type the following:

          link driver ne2000
               frame ethernet_802.3
               frame ethernet_802.2
               frame ethernet_ii
               frame ethernet_snap

          The first frame defined is the only one used for the initial "Get
          Nearest Server" request. Therefore, if some servers that are using
          only one frame type, such as Ethernet_802.3, put that frame type
          first. That way your workstation will be able to make a default
          connection to those servers.

          Important Whenever you edit the NET.CFG file, you must indent
          settings, as well as follow the other format requirements explained
          in "NET.CFG Format Requirements".

 3. Read the following to determine whether you need to specify a node address
 in the NET.CFG file.

     If you are using Extended Services or LAN Services set up for universally
     administered addresses

          You do not need to specify a node address. Go to Step 5.

     If you are using Extended Services or LAN Services set up for locally
     administered addresses

          You must specify a node address. Use the address shown in the
          "NetAddress" parameter in the PROTOCOL.INI file. Remove the T first.
          For example, if the PROTOCOL.INI file shows the line

          NetAddress = "T400000007030"

          the address you specify in NET.CFG is

          400000007030

          Go to Step 4.

 4. Type a line specifying the node address.

     Type this line under the "Link Driver" option, above or below the lines
     enabling frame types. The node address must be a 6byte hexadecimal number
     (12 characters). Use the address you located in Step 3.

     For example, to set a node address for a token ring board in an Extended
     Services environment, type:

     node address 400000007030

     If your board supports octet bit reversal, you can specify the address in
     either canonical (least significant bit first) or non-canonical (most
     significant bit first) format.

     By default, the following frames are non-canonical (MSB):

     Γûá Token ring

     Γûá PC Network II

     Ethernet frames are canonical (LSB).

     If you specify the address in the format that is not default, you must
     type an M (most significant bit first) or L (least significant bit first)
     at the end of the address to tell ODINSUP which format you used.

     For example, for a token ring environment using the default format for the
     node address, the "Current NET.CFG file contents" box should contain lines
     similar to the following:

     link driver token
          frame token-ring
          frame token-ring_snap
          node address 400000007030

     Note that an M after the node address is not needed because the address
     specifies most significant bit first, the default format for token ring.

     For a token ring environment using the non-default format for the same
     node address, the "Current NET.CFG file contents" box should contain lines
     similar to the following:

     link driver token
          frame token-ring
          frame token-ring_snap
          node address 020000000E0CL

     In this case, an L after the node address is needed because the address is
     specified in least significant-bit-first format, the format which is not
     the default for token ring.

     For an Ethernet Extended Services environment, the NET.CFG file should now
     contain lines similar to the following:

     link driver ne2000
          frame ethernet_802.3
          frame ethernet_802.2
          frame ethernet_ii
          frame ethernet_snap
          node address 00001B1B055C

 NoteIf you don't know the node address, you can type a "dummy" address and
 continue. When you reboot your machine, a message showing the correct address
 will appear. At that point, you can edit the NET.CFG file again and insert the
 address that was displayed at boot time.

 5. Bind ODINSUP to one or more ODI drivers.

     When ODINSUP is bound to a driver, the network board for that driver is
     used for Extended Services and LAN Services transmissions.

     5a. Add the following lines:

          protocol odinsup
             bind drivername

          Replace drivername with the name of the ODI driver you installed with
          NetWare Client for OS/2.

          For example, for a token ring ODI driver, type

          protocol odinsup
             bind token

     5b. (Conditional) Specify an instance number if you have two or more
     boards using the same ODI driver.

          If you have two or more network boards using the same ODI driver,
          ODINSUP searches the network board slots in order and binds only to
          the first board of that type it finds.

          To have ODINSUP bind to a board other than the first one found, you
          specify an instance number.

          ODINSUP can be bound to a maximum of four boards.

          For example, if you have two token ring network boards, bind ODINSUP
          to both boards by typing an instance number for the second board, as
          shown:

          protocol odinsup
             bind token
             bind token 2

 6. (Optional) Increase the size of the packet transmitted through the Link
 Support Layer.

     Increasing the packet size may improve transmission speed if you are using
     a Token Ring 16/4 board.

     For other kinds of board, see the board documentation to determine the
     maximum packet size supported by the board. If the board supports a packet
     size larger than 1514, (the Link Support default), transmission speed may
     improve if you increase the Link Support Layer default to the board's
     maximum allowed size.

     To increase the default,

     6a. Under the Link driver lines, type the following line:

          link support

     6b. Under the Link Support line, type the following line:

          buffers number size

          Indent the line. Replace Replace number with a number of buffers
          greater than 1. Replace buffer_size with a number of bytes greater
          than 576.

          NetWare Client for OS/2 cannot use more than 64 KB of memory for
          communication buffers. Header information takes 5 KB. This means that
          the buffer number multiplied by the buffer size (plus the header
          information) cannot be greater than 65,536 bytes. For example, 20
          buffers multiplied by 1514 bytes equals 30,280 bytes.

          For example, you might type

          link support
             buffers 14 4202

 Important For Token Ring 16/4 boards, NetWare Client for OS/2 will probably
 have maximum performance if you specify 14 buffers, each with a size of 4202
 bytes, as shown in the example above.

 7. Save your changes and exit the NET.CFG file.

 8. Exit the text editor.

 9. Choose "Shutdown" from the OS/2 System menu to reboot your machine.

     When your machine starts again, ODINSUP support will be completely set up.
     NetWare Client for OS/2 and Extended Services/LAN Services will then use
     the same ODI driver and board to transmit on the network.


ΓòÉΓòÉΓòÉ 16.2.4. Sample Configuration Files for ODINSUP ΓòÉΓòÉΓòÉ

Sample Configuration Files for ODINSUP

This section contains sample CONFIG.SYS, NET.CFG, and PROTOCOL.INI files for
both Extended Services and LAN Requester environments.

NoteIf you follow the steps in "Setting Up ODINSUP", your configuration files
will look like the ones shown. We recommend following the steps rather than
just referring to these sample files.

ODINSUP Files for an Extended Services Environment

These files came from a computer with the following software installed:

Γûá OS/2 2.1

Γûá Extended Services 1.0 (locally-administered addresses)

Γûá NetWare Client for OS/2 with ODINSUP.

The computer used Communications Manager to make a LAN connection to an IBM
host.

Sample Files

Extended Services Token Ring PROTOCOL.INI File for ODINSUP

Extended Services Token Ring CONFIG.SYS File for ODINSUP

Extended Services Token Ring NET.CFG File for ODINSUP

ODINSUP Files for a LAN Requester Environment

These files came from a computer with the following software installed:

Γûá OS/2 2.1

Γûá LAN Requester 2.0

Γûá NetWare Client for OS/2 with ODINSUP

Sample Files

LAN Requester Token Ring PROTOCOL.INI File for ODINSUP

LAN Requester Token Ring CONFIG.SYS File for ODINSUP

LAN Requester Token Ring NET.CFG File for ODINSUP


ΓòÉΓòÉΓòÉ 16.2.5. Extended Services Token Ring PROTOCOL.INI File for ODINSUP ΓòÉΓòÉΓòÉ

Extended Services Token Ring PROTOCOL.INI File for ODINSUP


ΓòÉΓòÉΓòÉ 16.2.6. Extended Services Token Ring CONFIG.SYS File for ODINSUP ΓòÉΓòÉΓòÉ

Extended Services Token Ring CONFIG.SYS File for ODINSUP


ΓòÉΓòÉΓòÉ 16.2.7. Extended Services Token Ring NET.CFG File for ODINSUP ΓòÉΓòÉΓòÉ

Extended Services Token Ring NET.CFG File for ODINSUP


ΓòÉΓòÉΓòÉ 16.2.8. Requester Token Ring PROTOCOL.INI File for ODINSUP ΓòÉΓòÉΓòÉ

Requester Token Ring PROTOCOL.INI File for ODINSUP


ΓòÉΓòÉΓòÉ 16.2.9. LAN Requester Token Ring CONFIG.SYS File for ODINSUP ΓòÉΓòÉΓòÉ

LAN Requester Token Ring CONFIG.SYS File for ODINSUP


ΓòÉΓòÉΓòÉ 16.2.10. LAN Requester Token Ring NET.CFG File for ODINSUP ΓòÉΓòÉΓòÉ

LAN Requester Token Ring NET.CFG File for ODINSUP


ΓòÉΓòÉΓòÉ 16.3. Setting Up LANSUP ΓòÉΓòÉΓòÉ

Setting Up LANSUP

NoteExcept where noted, the instructions in this section apply whether you have
Extended Services, LAN Services, or both. However, the sample configuration
files shown differ depending on what IBM software you have. Be sure to refer to
the correct files for your environment.

Setting up LANSUP involves three parts. The first two parts are required; the
third is optional.

Part A: Loading LANSUP in CONFIG.SYS

Part B: Configuring LANSUP in NET.CFG

Part C: Increasing Packet Size for LANSUP (Optional)

Sample Configuration Files for LANSUP

Novell's LAN Support (LANSUP) device driver replaces the CMGRLAN and TOKENEE
modules used in NetWare Client for OS/2 1.3.  CMGRLAN and TOKENEE are not
supported in NetWare Client for OS/2  2.1.

LANSUP works with NDIS drivers for PC Network II, Ethernet, and Token-Ring
network boards.


ΓòÉΓòÉΓòÉ 16.3.1. Part A: Loading LANSUP in CONFIG.SYS ΓòÉΓòÉΓòÉ

Part A: Loading LANSUP in CONFIG.SYS

In this section, you use the NetWare Client for OS/2 Installation program to
load LANSUP in the CONFIG.SYS file.

If you have not yet installed NetWare Client for OS/2, you can install it at
the same time as you install LANSUP.

NoteThese instructions are for LAN Server and LAN Requester version 2.x.

Prerequisites

 Install Extended Services on the workstation. Verify that you can get a
Communications Manager or Database Manager connection. See the documentation
for Extended Services.

 Install LAN Server or LAN Requester on the workstation. Verify that you can
get a connection on your LAN Server network. See the documentation for LAN
Services.

Procedure 1. Start the NetWare Client for OS/2 Installation program.

     If NetWare Client for OS/2 is not installed, you can start the program
     from your WSOS2_1 diskette. Type INSTALL. You can install NetWare Client
     for OS/2 with this procedure.

     If NetWare Client for OS/2 is already installed, you can start the program
     by choosing the "Installation" icon from the "Novell" group on your
     desktop.

 2. Choose "Requester on Workstation" from the "Installation" menu.

 3. Verify the target and source directory and choose "OK."

 4. Select an action from the "Requester Installation" screen based on whether
 NetWare Client for OS/2 is installed.

     4a. If NetWare Client for OS/2 is not installed, select "Edit CONFIG.SYS
     and Copy All Files . . . " and choose "OK."

     4b. If NetWare Client for OS/2 is installed, select "Only Edit CONFIG.SYS
     . . ." and choose "OK."

 5. Select LANSUP as the ODI LAN driver for your network board and choose
 "Continue..."

     Selecting LANSUP inserts the following line in the correct place in your
     CONFIG.SYS file:

     DEVICE=drive:\NETWARE\LANSUP.SYS

 6. Select your preferences for NetWare support for DOS and Windows
 applications and choose "Continue . . ."

 7. Select your preferences for optional protocol support and choose "Save . .
 ."

 8. Verify the filename and location and choose "OK."

     If you have not installed NetWare Client for OS/2, the "Copy Requester
     Files" screen appears. Continue with Step 9.

     If you have installed NetWare Client for OS/2, the main installation menu
     appears. Go to "Part B: Configuring LANSUP in NET.CFG".

 9. Choose "Copy" and follow the screens to finish installing NetWare Client
 for OS/2.

     When the main menu returns, go to "Part B: Configuring LANSUP in NET.CFG".


ΓòÉΓòÉΓòÉ 16.3.2. Part B: Configuring LANSUP in NET.CFG ΓòÉΓòÉΓòÉ

Part B: Configuring LANSUP in NET.CFG

Important A NET.CFG file is required to use LANSUP.

In this section, you edit or create a NET.CFG file that does the following:

Γûá Enables frame types for LANSUP

Γûá Specifies to LANSUP the node address used by the network board and the format
that address is transmitted in

In this section, you also decide whether to increase the size of the packet
that can be transmitted through LANSUP.

Prerequisite

 Install NetWare Client for OS/2 with LANSUP by following the instructions in
"Part A: Loading LANSUP in CONFIG.SYS"

Procedure 1. Choose "This workstation . .." from the "Configuration" menu of
the NetWare Client for OS/2 Installation program.

     If the NetWare Client for OS/2 Installation program is not running,
     complete the steps in "Part A: Loading LANSUP in CONFIG.SYS" and then
     return here.

 2. Verify the location of the NET.CFG file and choose "Edit."

     The "Edit NET.CFG" window appears.

     You can choose a topic in the "NET.CFG Options" box on this screen to get
     information about a topic. Then read the help window at the bottom of the
     screen.

     Choose the "Usage," "Description" and "Example" buttons on the right of
     your screen to see more information about the topic you've selected.

     For example, to see what frame types are supported for token ring drivers,
     choose "frame" from under "Link Driver" in the "NET.CFG Options" box. Then
     read the information in the help window.

 3. In the "Current NET.CFG File Contents" box, type the following line:

     link driver lansup

 4. Under the Link Driver line, type lines to enable at least one frame type.

     LANSUP can be used with Ethernet, token ring, and PCNet boards. The table
     below lists the supported frame types for LANSUP:

     List of Frame Types Supported by LANSUP

     Board          Frame types supported
     Token ring     TOKEN-RING, TOKEN-RING_SNAP
     Ethernet       ETHERNET_802.2, ETHERNET_SNAP
     PCNet          IBM_PCN2_802.2, IBM_PCN2_SNAP

     For example, to enable a frame type for token ring, type the following:

     link driver lansup
          frame token-ring

     To enable both frame types for Ethernet, type the following:

     link driver lansup
          frame ethernet_802.2
          frame ethernet_snap

     The first frame defined is the only one used for the initial Get Nearest
     Server request. Therefore, if you have some servers that are using only
     one frame type, such as Ethernet 802.3, put that frame type first. That
     way your workstation will be able to make a default connection to those
     servers.

     Important Use the Space bar to indent the lines. The <Tab> key moves you
     to the next box on the screen. Put a blank line at the end of the file.

     You must follow these and other format requirements explained in the
     "Format of NET.CFG Options" topic. To see these requirements, select this
     topic from the "NET.CFG Options" box and choose the "Usage" button. Then
     read the information in the help window at the bottom of the screen.

 5. Determine what node address you should use.

     If you are using Extended Services or LAN Services set up for universally
     administered addresses

          Use the address assigned to the board by the vendor.

     Extended Services or LAN Services set up for locally administered
     addresses.

     Use the address shown in the "NetAddress" parameter in the PROTOCOL.INI
     file. Remove the T first. For example, if the PROTOCOL.INI file shows the
     line

     NetAddress = "T400000007030"

     the address you specify in NET.CFG is

     400000007030

 6. Type a line specifying the node address.

     Type this line under the "Link Driver" option, above or below the lines
     enabling frame types. The node address must be a 6 byte hexadecimal number
     (12 characters).

     For example, to set a node address for a token ring board in a LAN
     Services environment, type:

          node address 10005a8c62d4

     If your board supports octet bit reversal, you can specify the address in
     either  canonical (least significant bit first) or non-canonical (most
     significant bit first) format.

     By default, the following frames are non-canonical (MSB):

     Γûá Token ring

     Γûá PC Network II

     Ethernet frames are canonical (LSB).

     If you specify the address in the format that is not default, you must
     type an M (most significant bit first) or L (least significant bit first)
     at the end of the address to tell ODINSUP which format you used.

     For example, for a token ring environment using the default format for the
     node address, the "Current NET.CFG file contents" box should contain lines
     similar to the following:

     link driver lansup
          frame token-ring
          node address 10005a8c62d4

     Note that an M after the node address is not needed because the address is
     specified most significant bit first, the default format for token ring.

     For a token ring environment using the non-default format for the same
     node address, the "Current NET.CFG file contents" box should contain lines
     similar to the following:

     link driver lansup
          frame token-ring
          node address 08005A31462BL

     In this case, an L after the node address is needed because the address is
     specified in least significant bit first format, the format which is not
     the default for token ring.

     For an Ethernet environment, the "Current NET.CFG file contents" box
     should contain lines similar to the following:

     link driver lansup
          frame ethernet_802.2
          frame ethernet_snap
          node address 00001B1B055C

 NoteIf you do not know the node address, you can type a "dummy" address and go
 to the next step. When you reboot your machine, a message showing the correct
 address will appear. At that point, you can edit NET.CFG again and insert the
 address that was displayed at boot time.

 7. Decide whether to increase the size of the packet transmitted to the NDIS
 driver by LANSUP.

     Increasing the packet size may improve transmission speed if you are using
     a Token Ring 16/4 board.

     For other kinds of board, see the board documentation to determine the
     maximum packet size supported by the board. If the board supports a packet
     size larger than the Link Support Layer default, transmission speed may
     improve if you increase the Link Support Layer default to the board's
     maximum allowed size.

     7a. To increase the packet size, go to "Part C: Increasing Packet Size for
     LANSUP (Optional)."

     7b. If you do not want to increase the packet size, go to Step 8.

 8. Choose "Save . . ."

 9. Exit the NetWare Client for OS/2 Installation program.

 10. Choose "Shutdown" from the OS/2 System menu to reboot your machine.

     When your computer starts again, LANSUP support will be set up. NetWare
     Client for OS/2 and Extended Services or LAN Services will then use the
     same NDIS driver and board to transmit on the network.


ΓòÉΓòÉΓòÉ 16.3.3. Part C: Increasing Packet Size for LANSUP (Optional) ΓòÉΓòÉΓòÉ

Part C: Increasing Packet Size for LANSUP (Optional)

Complete this section only if you were directed to come here from a previous
section.

In this section, you

Γûá Edit NET.CFG to increase the size of the packet that can be transmitted
through LANSUP.

Γûá Edit PROTOCOL.INI to increase the size of the packet that can be transmitted
through the NDIS drivers.

Prerequisite

 Install NetWare Client for OS/2 with LANSUP by following the instructions in
Part A: Loading LANSUP in CONFIG.SYS.

 Follow the instructions in Part B: Configuring LANSUP in NET.CFG.

Procedure 1. Select "Link support" in the "NET.CFG Options" box on the left of
your screen.

     If the NetWare Client for OS/2 Installation program is not open to the
     "Edit NET.CFG Window", complete the steps in Part B: Configuring LANSUP in
     NET.CFG Then come back to this step.

 2. Select "buffers" under "Link Support."

 3. Read the information in the help window at the bottom of the screen to see
 how to set the Link Support buffers.

     You can choose the "Usage," "Description" and "Example" buttons on the
     right of your screen to see more information about Link Support.

 4. In the "Current NET.CFG File Contents," add lines to change the "Link
 Support buffers" setting.

     Follow the usage requirements shown in the help window.

     Indent the line. Replace number with a number of buffers greater than 1.
     Replace buffer_size with a number of bytes greater than 576.

     NetWare Client for OS/2 cannot use more than 64 KB of memory for
     communication buffers. Header information takes 5 KB of memory. This means
     that the buffer number multiplied by the buffer size (plus the header
     information) cannot be greater than 65,536 bytes. For example, 20 buffers
     multiplied by 1514 bytes equals 30,280 bytes.

     For example, you might type

     link support
          buffers 14 4202

 Important For Token Ring 16/4 boards, NetWare Client for OS/2 will probably
 have maximum performance if you specify 14 buffers, each with a size of 4,202
 bytes, as shown in the example above.

 5. Choose "Save . . ."

 6. Exit the NetWare Client for OS/2 Installation program. Without rebooting
 your machine, go to Step 7.

 7. Run the IBM LAPS program to edit PROTOCOL.INI.

 8. Change the transmit buffer size to a number 6 bytes larger than the number
 you set for the Link Support buffer size in Step 4.

     The value you specify must be a multiple of 8. See your LAPS documentation
     for more about changing the transmit buffer size.

 Important Use a transmit buffer size of 4,208 if you are using Token Ring 16/4
 boards.

     The LAPS program inserts the following line in the NDIS MAC driver section
     of your PROTOCOL.INI file:

     XMITBUFSIZE = 4208

 9. Exit the LAPS program.

 10. Choose "Shutdown" from the OS/2 System menu to restart your machine.

     When your machine starts again, LANSUP support will be set up.

     NetWare Client for OS/2 and Extended Services/LAN Services will transmit
     to the network from the same NDIS driver and network board.


ΓòÉΓòÉΓòÉ 16.3.4. Sample Configuration Files for LANSUP ΓòÉΓòÉΓòÉ

Sample Configuration Files for LANSUP

This section contains sample CONFIG.SYS, NET.CFG, and PROTOCOL.INI files for
both Extended Services and LAN Requester environments.

NoteIf you follow the steps in "Setting Up LANSUP",  your configuration files
will look like the ones shown. We recommend following the steps rather than
just referring to these sample files.

LANSUP Files for an Extended Services Environment

These files came from a computer with the following software installed:

Γûá OS/2 Version 2.1

Γûá Extended Services version 1.0 (locally-administered addresses)

Γûá NetWare Client for OS/2 with LANSUP.

The computer used Communications Manager to make a LAN connection to an IBM
host.

Sample Files

Extended Services Token Ring CONFIG.SYS File for LANSUP

Extended Services Token Ring NET.CFG File for LANSUP

Extended Services Token Ring PROTOCOL.INI File for LANSUP

ODINSUP Files for a LAN Requester Environment

These files came from a computer with the following software installed:

Γûá OS/2 v2.1

Γûá LAN Requester v2.0

Γûá NetWare Client for OS/2 with LANSUP

Sample Files

LAN Requester Token Ring CONFIG.SYS File for LANSUP

LAN Requester Token Ring NET.CFG File for LANSUP

LAN Requester Token Ring PROTOCOL.INI File for LANSUP


ΓòÉΓòÉΓòÉ 16.3.5. Extended Services Token Ring CONFIG.SYS File for LANSUP ΓòÉΓòÉΓòÉ

Extended Services Token Ring CONFIG.SYS File for LANSUP


ΓòÉΓòÉΓòÉ 16.3.6. Extended Services Token Ring NET.CFG File for LANSUP ΓòÉΓòÉΓòÉ

Extended Services Token Ring NET.CFG File for LANSUP


ΓòÉΓòÉΓòÉ 16.3.7. Extended Services Token Ring PROTOCOL.INI File for LANSUP ΓòÉΓòÉΓòÉ

Extended Services Token Ring PROTOCOL.INI File for LANSUP


ΓòÉΓòÉΓòÉ 16.3.8. LAN Requester Token Ring CONFIG.SYS File for LANSUP ΓòÉΓòÉΓòÉ

LAN Requester Token Ring CONFIG.SYS File for LANSUP


ΓòÉΓòÉΓòÉ 16.3.9. LAN Requester Token Ring NET.CFG File for LANSUP ΓòÉΓòÉΓòÉ

LAN Requester Token Ring NET.CFG File for LANSUP


ΓòÉΓòÉΓòÉ 16.3.10. LAN Requester Token Ring PROTOCOL.INI File for LANSUP ΓòÉΓòÉΓòÉ

LAN Requester Token Ring PROTOCOL.INI File for LANSUP


ΓòÉΓòÉΓòÉ 17. NET.CFG Options Reference ΓòÉΓòÉΓòÉ

NET.CFG Options Reference

This is an alphabetical listing of all NET.CFG options. For instructions on
editing the NET.CFG file, format requirements, and reasons to configure, see
Configuring NetWare Client for OS/2.

All the information in this appendix is also found online in the NetWare
Requester installation and configuration program.

Topics

     Daemon Configuration
     Link Driver
     Link Support
     Named Pipes
     NetWare NetBIOS
     NetWare Requester
     Protocol ODINSUP
     Protocol Stack IPX
     Protocol Stack SPX
     Token-Ring Source-Route Driver


ΓòÉΓòÉΓòÉ 17.1. Daemon Configuration ΓòÉΓòÉΓòÉ

Daemon Configuration

Use this option to control the length of time network-related error messages
stay on your screen. This option controls only pop-up and broadcast messages.

NotePop-up and broadcast messages appear in a small box on your screen and
prompt you to "Press <Esc> to continue ..."

Syntax

     daemon configuration
        message timeout number

 Message timeout

     Replace number with a number of milliseconds that you want pop-up and
     broadcast messages to display on your screen before disappearing.

     Replace number with 0 (zero) to prevent pop-up and broadcast messages from
     displaying at all.

     If you leave this line out of your NET.CFG, pop-ups and broadcast messages
     are displayed until you press <Esc>.

 Default

 Pop-up and broadcast messages display until you press <Esc>.

 Example

 To prevent pop-up and broadcast messages from displaying:

     daemon configuration
        message timeout 0


ΓòÉΓòÉΓòÉ 17.2. Link Driver ΓòÉΓòÉΓòÉ

Link Driver

Use this option to specify the hardware configuration of the LAN drivers for
each network board in your workstation.

Use this option only if the network boards are not using the default settings.
The settings you specify with this option should match the hardware settings
for your boards.

NoteIf you have more than one network board in your workstation, put this
option in your NET.CFG file for each board.

Syntax

     link driver name
        alternate
        dma [index] channel
        frame name
        int [index] irq
        mem [index] starting_address [size]
        node address number
        port [index] starting_port [number]
        protocol name id frame
        slot number


ΓòÉΓòÉΓòÉ 17.2.1. link driver ΓòÉΓòÉΓòÉ

link driver

Use this option to specify the name of the LAN driver whose defaults you want
to modify.

Syntax

     link driver name

 Replace name with the name of the driver. The List of Network Boards and
 Drivers lists some network boards and their driver names.

 Default

     None.

 Example

 To configure an IBM Token-Ring PC driver, type the following with any
 settings.

     link driver token


ΓòÉΓòÉΓòÉ 17.2.2. alternate ΓòÉΓòÉΓòÉ

alternate

Specifies an alternate board. Normally, the LANSUP, IBM token ring and NTR2000,
and PCN2L drivers use the primary board.

Syntax

     link driver name
        alternate

 Default

 None

 Example

 To specify the LANSUP.COM driver to use an alternate board, you would place
 the following lines in your NET.CFG file:

     link driver name
        alternate


ΓòÉΓòÉΓòÉ 17.2.3. DMA ΓòÉΓòÉΓòÉ

DMA

Use this setting to specify which direct memory access (DMA) channel the
network board uses.

Syntax

     link driver name
        dma [index] channel

 Replace index with either #1 or #2 (optional).

 The driver configuration table for each board can store the DMA channel number
 on either of two lines. The lines are labeled #1 and #2.

 Replace channel with the number of the DMA channel used by the board.

 The channel numbers for different network boards are recorded in the
 documentation from the board manufacturers.

 Defaults

 Index: #1

 Most boards use this default.

 Channel: Set by the driver. See the documentation for the board.

 You can't change the DMA setting on 3Com Etherlink 503 boards, and you do not
 need to change it on 3Com Etherlink 505 boards. You can change the DMA setting
 on 3Com Etherlink 523 boards.

 Example

 To set the DMA channel for a 3Com Etherlink 505 board:

     link driver 3C505
        dma 7


ΓòÉΓòÉΓòÉ 17.2.4. frame ΓòÉΓòÉΓòÉ

frame

Use this setting to specify which frame type the driver for your network board
uses.

Use this setting only for boards that support more than one frame type or if
you want multiple networks (separate network addresses) to share the same
network board and cabling.

The frame type transmitted by the workstation should match the type of packets
being transmitted by the servers on your network.

Syntax

     link driver name
        frame name

 Replace name with the name of the frame type. The Frame Types and LAN Drivers
 table lists common frame types and the network board drivers that support each
 type. This list is not comprehensive.

 Default

 Set by the driver. See the documentation for the board.

 Examples

 To specify the Ethernet_802.2 frame type for an NE2000 board:

     link driver ne2000
        frame ethernet_802.2

 To specify the Ethernet_802.2 and Ethernet_802.3 frame types for an NE1000
 board (for two logical networks):

     link driver ne1000
        frame ethernet_802.2
        frame ethernet_802.3

 If you are using the ODINSUP driver, you must enable multiple frame types for
 each driver. For Ethernet, enable Ethernet_802.3, Ethernet_II, Ethernet_802.2,
 and Ethernet_SNAP.

 For Token-Ring, enable Token-Ring and Token-Ring_SNAP. For more information
 about ODINSUP, see Using ODINSUP and LANSUP

 You can specify more than one frame type statement for a single driver. For
 example, you can specify that an Ethernet NE2000 board can use both
 Ethernet_802.2 and Ethernet_802.3 frame types. 802.2 is the type of
 communications sent on one network, and 802.3 is the type of communication
 sent on the other network.

 You can use up to four frame types for one set of Ethernet cabling. You can
 use either four network boards each with one frame type defined, or you can
 use one network board with four frames defined, or any similar combination.

 For Token-Ring cabling, two frames types are the maximum allowed.

 The default frame type for Ethernet drivers has changed to Ethernet_802.2.
 This may conflict with the frame type used on your network. See Specifying
 Frame Types for a LAN Driver for more information about specifying frame type.


ΓòÉΓòÉΓòÉ 17.2.5. int ΓòÉΓòÉΓòÉ

int

Use this setting to specify which interrupt line (IRQ) the network board uses
to communicate with the driver.

Syntax

     link driver name
        int [index] irq

 Replace index with either #1 or #2 (optional).

 The driver configuration table for each board can store the interrupt line
 number on either of two lines in the table. The lines are labeled #1 and #2.

 Replace irq with the number of the interrupt line used by the board.

 To determine the interrupt line number for your network board, see the
 documentation for the board.

 Defaults

 Index: #1

 IRQ: Set by the driver. See the documentation for the board.

 Example

 To set the interrupt line for an NE2000 board:

     link driver ne2000
        int 3

 Before changing the interrupt setting for your board, be sure you know what
 interrupt settings are used on other hardware (such as monitors) that you are
 using. For example, interrupts 2 and 9-15 are usually reserved, so don't use
 those numbers (especially 2) for your network board. We recommend using 3, 5,
 or 7 for most network boards.

 If you are using a PS/2 computer on a Token-Ring network, do not autoconfigure
 with the Reference diskette. Doing so may cause problems.


ΓòÉΓòÉΓòÉ 17.2.6. mem ΓòÉΓòÉΓòÉ

mem

Use this setting to specify what range of memory can be used by the driver.

Syntax

     link driver name
        mem [index] starting_address size

 Replace index with either #1 or #2 (optional).

 The driver configuration table for each board can store the memory range on
 either of two lines in the table. The lines are labeled #1 and #2.

 Replace starting_address with a hexadecimal memory address that begins the
 range. This address must be five digits and the same as the address designated
 for the board by the manufacturer. (See the documentation for the board).

 Replace size with a hexadecimal number of paragraphs in the memory range
 (optional).

 Defaults

 "Index: #1" = ROM address

 "Index: #2" = RAM address (D8000 by default by TOKEN.SYS)

 Starting_address: Set by the driver. See the documentation for the board.

 Size: Set by the driver. See the documentation for the board.

 Example

 To set the memory range for a Token-Ring board:

     link driver token
        mem cc000 200

 Assign each board a unique memory range. Be sure that you don't assign a range
 that is already being used by other hardware. (VGA monitors commonly use
 A0000-C6FFF and XVGA monitors commonly use A0000-CFFFF.)


ΓòÉΓòÉΓòÉ 17.2.7. node address ΓòÉΓòÉΓòÉ

node address

Use this setting to change the node address of a network board. This setting
can only be used with network boards that allow you to override the preset
address.

Syntax

     link driver name
        node address number

 Replace number with a hexadecimal address. You can specify the address with
 either the least significant bit first (lsb format) or the most significant
 bit first (msb format).

 Default

 The address preset on the board.

 Example

 To change the address for board that uses the ODINSUP driver:

     link driver odinsup
        node address 02608c861759


ΓòÉΓòÉΓòÉ 17.2.8. port ΓòÉΓòÉΓòÉ

port

Use this setting to specify which range of I/O ports the network board uses.

Syntax

     link driver name
        port [index] starting_port [number]

 Replace index with either #1 or #2 (optional).

 The driver configuration table for each board can store information about
 ports on either of two lines in the table. The lines are labeled #1 and #2.

 Replace starting_port with a hexadecimal port number that begins the range. We
 recommend not using 2EO and 2FO since these port numbers are normally used by
 ARCnet for other functions.

 Replace number with the hexadecimal number of bytes in the range (optional).

 Defaults

 Index: #1

 Starting_port: Set by the driver. See the documentation for the board.

 Number: Set by the driver. See the documentation for the board.

 Example

 To set the memory range for board that uses the NE2000 driver:

     link driver ne2000
        port 300


ΓòÉΓòÉΓòÉ 17.2.9. protocol ΓòÉΓòÉΓòÉ

protocol

Use this setting to allow LAN drivers to use protocols that have different
frame types.

Syntax

     link driver name
        protocol name ID frame

 Replace name with the acronym of an ODI-compliant protocol. Some common
 protocols are:

 ARP
 IP
 IPX (the NetWare protocol)
 RARP

 Replace ID with the hexadecimal number of the protocol that goes with the
 frame type you specify.

 Replace frame with the name of the frame type used with the protocol. The
 Protocol and Frame type table shows common protocols with some frame types and
 hexadecimal numbers they support.

 Defaults

 Name: IPX

 ID: 0

 Frame: Ethernet_802.3

 Example

 To specify the ARP protocol for an Ethernet II frame:

     link driver NE2000
        protocol arp 806 ethernet_ii


ΓòÉΓòÉΓòÉ 17.2.10. slot ΓòÉΓòÉΓòÉ

slot

Use this setting to tell the NetWare Client for OS/2 which expansion slot an
EISA or Microchannel board is using.

EISA and Microchannel boards are self-configuring, and the NetWare Client for
OS/2 can obtain all Link Driver information from the board itself. You have to
tell the NetWare Client for OS/2 which slot the board is using or, if you only
have one board of a particular type, tell the NetWare Client for OS/2 to scan
all slots until it finds that board.

Syntax

     link driver name
        slot number

 Replace number with the number of the expansion slot the board is using or a
 question mark to tell NetWare Client for OS/2 to scan all slots.

 Default

 None

 Example

 To automatically configure the drivers for an NE/2 board in slot 4 and an NE/2
 board in slot 2:

     link driver ne2
        slot 4

     link driver ne2
        slot 2

 This slot setting is the only Link Driver hardware-related setting you need to
 specify in this case.

 To scan all slots for a Novell Ethernet NE/2 board:

     link driver ne2
        slot ?


ΓòÉΓòÉΓòÉ 17.2.11. LAN Driver Table ΓòÉΓòÉΓòÉ

List of Network Boards and Driver Table

This table is a list of common network boards and drivers

 Driver name    Network board

 NE2            Novell Ethernet NE/2

 NE2_32         Novell Ethernet NE/2-32

 NE1000         Novell Ethernet NE1000

 NE2000         Novell Ethernet NE2000

 TOKEN          IBM Token ring

 LANSUP         Boards using NDIS drivers

 ODINSUP        IBM Token ring and Ethernet Communications Manager

 3C501          3Com EtherLink series 501

 3C503          3Com EtherLink series 503

 3C505          3Com EtherLink series 505

 3C523          3Com EtherLink/MC series

 PCN2           IBM PC Network II and II/A (older Novell frame format)

 PCN2L          IBM PC Network II and II/A (newer IBM frame format)

 NoteThe PCN2 and PCN2L drivers cannot be used in the same workstation.


ΓòÉΓòÉΓòÉ 17.2.12. List of Frame Types and LAN Drivers ΓòÉΓòÉΓòÉ

List of Frame Types and LAN Drivers

 Frame type          LAN board driver

 Ethernet 802.3      NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503, 3C505,
                     3C523, EXOS205, EXOS215, ODINSUP

 Ethernet 802.2      NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503,
                     EXOS205, EXOS215, ODINSUP, LANSUP

 Ethernet II         NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503, 3C505,
                     3C523, EXOS205, EXOS215, ODINSUP

 Ethernet SNAP       NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503,
                     EXOS205, EXOS215, ODINSUP, LANSUP

 Token ring          ODINSUP, TOKEN, LANSUP

 Token ring SNAP     ODINSUP, TOKEN, LANSUP

 IBM pcn2 802.2      PCN2, PCN2L, LANSUP

 IBM pcn2 snap       PCN2, PCN2L, LANSUP

 Novell rx-net       TRXNET, TRXNET2


ΓòÉΓòÉΓòÉ 17.2.13. Protocols and Frame types ΓòÉΓòÉΓòÉ

List of protocols, frame types, and hexadecimal ID numbers

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéProtocol  ΓöéFrame type     ΓöéHex numberΓöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéIPX       ΓöéEthernet_802.3 Γöé0         Γöé
Γöé          ΓöéEthernet_802.2 ΓöéE0        Γöé
Γöé          ΓöéToken-Ring     ΓöéE0        Γöé
Γöé          ΓöéIBM_PCN2_802.2 ΓöéE0        Γöé
Γöé          ΓöéEthernet_II    Γöé8137      Γöé
Γöé          ΓöéEthernet_SNAP  Γöé8137      Γöé
Γöé          ΓöéToken-Ring_SNAPΓöé8137      Γöé
Γöé          ΓöéIBM_PCN2_SNAP  Γöé8137      Γöé
Γöé          ΓöéNovell_RX-Net  ΓöéFA        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéIP        ΓöéEthernet_II    Γöé800       Γöé
Γöé          ΓöéEthernet_SNAP  Γöé800       Γöé
Γöé          ΓöéToken-Ring_SNAPΓöé800       Γöé
Γöé          ΓöéNovell_RX-Net  ΓöéD4        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéARP       ΓöéEthernet_II    Γöé806       Γöé
Γöé          ΓöéEthernet_SNAP  Γöé806       Γöé
Γöé          ΓöéToken-Ring_SNAPΓöé806       Γöé
Γöé          ΓöéNovell_RX-Net  ΓöéD5        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéRARP      ΓöéEthernet_II    Γöé8035      Γöé
Γöé          ΓöéEthernet_SNAP  Γöé8035      Γöé
Γöé          ΓöéToken-Ring_SNAPΓöé8035      Γöé
Γöé          ΓöéNovell_RX-Net  ΓöéD6        Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 17.3. Link Support ΓòÉΓòÉΓòÉ

Link Support

Use this option to adjust the number and size of communication buffers used by
NetWare Client for OS/2.

Syntax

     link support
        buffers number [buffer_size]

 buffers

 Replace number with a number of buffers greater than 1.

 Replace buffer_size with a number of bytes greater than 576.

 The NetWare Client for OS/2 cannot use more than 64 KB of memory for
 communication buffers. Header information takes 5 KB. This means that the
 buffer number multiplied by the buffer size (plus the header information)
 cannot be greater than 65,536 bytes. For example, 20 buffers multiplied by
 1514 bytes equals 30,280 bytes.

 Defaults

 Number: 20 buffers

 Buffer_size: 1514 bytes

 Examples

 For an Ethernet configuration:

     link support
        buffers 15 1514

 For a Token-Ring configuration:

     link support
        buffers 14 4210

 Notes

 1. Increasing efficiency. For most efficient communication, your link support
 buffer size should be the same size as the packets that your workstation will
 receive over the network. You may want to set the link support buffer size
 equal to the largest buffer size that the network boards in your workstation
 will support.

 2. Using the TRXNET.SYS driver. If your workstation experiences performance
 problems running with TRXNET.SYS, you may need to reconfigure the number and
 size of link support buffers allowed. Set the following values:

     link support
        buffers 15 4202

 TRXNET.SYS only supports SMC100, 110, and 120 cards.


ΓòÉΓòÉΓòÉ 17.4. Named Pipes ΓòÉΓòÉΓòÉ

Named Pipes

Use this option to manage Named Pipes sessions.

Syntax

     named pipes
        advertise board board number
        client sessions number
        machine names number


ΓòÉΓòÉΓòÉ 17.4.1. advertise board ΓòÉΓòÉΓòÉ

advertise board

Use this setting to specify a board that the Named Pipes server uses to
advertise itself. You should only configure more than one of this setting when
the boards specified are part of separate networks.

Syntax

 named pipes
     advertise board board number

 Replace board number with the logical board number of a network board. Board
 number can be a value from 1 to 16.

 Logical board numbers are assigned in ascending order to each frame type as
 they appear in your configuration. Note that logical board numbers are
 assigned to defaulted frame types.

 The board number given must be the logical board number of a frame type used
 by IPX. (Note: You specify IPX usage of a frame type by using the protocol
 setting under the link driver option.)

 Default

 The Named Pipes server will advertise itself over IPX's primary network board
 when this setting is not specified, out of range, or if the board number given
 does not match the logical board number of a frame type in use by IPX.

 Example

 Configure Named Pipes server as follows in order to use the logical boards
 defined by the NE2000 link driver and the Ethernet 802.2 and Ethernet 802.3
 frame types to advertise the server:

 Link Driver NE2
     Frame Ethernet_802.2;logical board 1
     Frame Ethernet_II;logical board 2
     Protocol IPX E0 Ethernet_802.2
     Protocol IP 800 Ethernet_II

 Link Driver NE2000
     Frame Ethernet_802.2;logical board 3
     Frame Ethernet_802.3;logical board 4
     Protocol IPX E0 Ethernet_802.2
     Protocol IPX 0 Ethernet_802.3

 Named Pipes
     Advertise Board 3
     Advertise Board 4


ΓòÉΓòÉΓòÉ 17.4.2. client sessions ΓòÉΓòÉΓòÉ

client sessions

Use this setting to specify the maximum number of connections a workstation can
establish with all Named Pipes servers.

Syntax

     named pipes
        client sessions number

 Replace number with a number from 3 to 128.

 You need at least one client session for each connection from an OS/2
 application to a Named Pipes server.

 Default

 16 sessions.

 The default is usually adequate, except with applications that use many Named
 Pipes.

 Example

 To allow each client thirty sessions:

     named pipes
        client sessions 30


ΓòÉΓòÉΓòÉ 17.4.3. machine names ΓòÉΓòÉΓòÉ

macine names

Use this setting to force Named Pipes to create a local table of server names.
This is used in all sessions on an OS/2 client workstation. This setting is
necessary for remote Named Pipes operations when there are no NetWare servers
on the network.

Syntax

 named pipes
     machine names number

 Replace number with a number from 4 to 100. The number represents how many
 Named Pipes server names you want to cache.

 Default

 0 (i.e., query network for Named Pipes server names)

 Example

 To set the number of locally cached Named Pipes server names to 5:

 named pipes
     machine names 5


ΓòÉΓòÉΓòÉ 17.5. NetWare NetBIOS ΓòÉΓòÉΓòÉ

NetWare NetBIOS

Use this option to manage NetBIOS names and sessions or to affect the internal
memory allocation for NetBIOS.

Categories of NetWare NetBIOS settings

Name management

     Broadcast count
     Broadcast delay
     Internet
     Names

 Session creation

     Retry count
     Retry delay
     Sessions

 Session management

     Abort timeout
     Listen timeout
     Verify timeout

 Command management

     Commands

 Syntax

     netware netbios
        abort timeout number
        bind board number
        broadcast count number
        broadcast delay number
        commands number
        internet [on|off]
        listen timeout number
        names number
        retry count number
        retry delay number
        sessions number
        verify timeout number


ΓòÉΓòÉΓòÉ 17.5.1. Abort, Listen, and Verify Timeout ΓòÉΓòÉΓòÉ

abort, listen, and verify timeout

Use these settings to monitor and control your NetBIOS connections.

When NetBIOS sessions at a sending computer do not receive any transmissions
from the receiving computer for the length of the "verify timeout" interval,
NetBIOS sends a request-for-acknowledgment packet to the receiving computer.
NetBIOS then waits the length of the "listen timeout" interval to receive a
response.

If no response is received, NetBIOS sends another packet requesting immediate
response. NetBIOS then waits the length of the "abort timeout" interval to
receive a response.

If no response is received, NetBIOS terminates the session.

Syntax

     netware netbios
        abort timeout number
        listen timeout number
        verify timeout number

 Abort timeout: Replace number with a number of milliseconds greater than 500.

 Listen timeout: Replace number with a number of milliseconds greater than 200

 Verify timeout: Replace number with a number of milliseconds greater than 100.

 The ratio between these settings must remain the same. For example, if you
 double the Listen timeout value, you must also double the Abort timeout and
 Verify timeout values.

 Defaults

        Abort timeout: 30,000 milliseconds
        Listen timeout: 6,000 milliseconds
        Verify timeout: 3,000 milliseconds

 Examples

 To make NetBIOS wait longer before sending a request-for acknowledgment
 packet, sending the packet requesting immediate response, and terminating the
 session:

     netware netbios
        abort timeout 45000
        listen timeout 8000
        verify timeout 4000


ΓòÉΓòÉΓòÉ 17.5.2. broadcast count ΓòÉΓòÉΓòÉ

broadcast count

Use this setting to specify how many times NetBIOS broadcasts a query or claim
for the name being used by an application.

Syntax

     netware netbios
        broadcast count number

 Replace number with a number of queries greater than 1.

 Defaults

 With internet on: 4 times.

 With internet off: 2 times.

 Example

 To broadcast more often:

     netware netbios
        broadcast count 8


ΓòÉΓòÉΓòÉ 17.5.3. broadcast delay ΓòÉΓòÉΓòÉ

broadcast delay

Use this setting to specify how long NetBIOS waits between query or claim
broadcasts.

Syntax

     netware netbios
        broadcast delay number

 Replace number with a number of milliseconds greater than 100.

 Defaults

 With internet on: 2,000

 With internet off: 1,000

 Example

 To wait longer between broadcasts:

     netware netbios
        broadcast delay 3000


ΓòÉΓòÉΓòÉ 17.5.4. commands ΓòÉΓòÉΓòÉ

commands

Use this setting to specify how many NetBIOS commands can be buffered in the
NetBIOS driver at any one time.

Syntax

     netware netbios
        commands number

 Replace number with a number of commands from 8 to 128.

 Default

 32 commands

 Example

 To run an application that requires a large number of outstanding commands:

     netware netbios
        commands 128


ΓòÉΓòÉΓòÉ 17.5.5. internet ΓòÉΓòÉΓòÉ

internet

Use this setting to transmit name-claim packets to and from all stations on the
internet, or to and from stations on the local network only.

Name-claim packets are packets which attempt to establish the uniqueness of the
name of the station on which NetBIOS is running.

Syntax

     netware netbios
        internet [on|off]

 Type on or off

 Default

 On

 Example

 To send and receive on the local network only:

     netware netbios
        internet off


ΓòÉΓòÉΓòÉ 17.5.6. names ΓòÉΓòÉΓòÉ

names

Use this setting to specify how many names the workstation can have in its name
table for remote stations. When you add a name to a station, the station
broadcasts that name to all other nodes on the network.

Syntax

     netware netbios
        names number

 Replace number with a number of names from 4 to 128.

 You can use a name instead of a node address to refer to a remote station.

 Default

 24 names

 Example

 To allow forty-five names:

     netware netbios
        names 45


ΓòÉΓòÉΓòÉ 17.5.7. retry count ΓòÉΓòÉΓòÉ

retry count

Use this setting to specify how many times NetBIOS transmits a request for
connection or retransmits a failed communication.

Syntax

     netware netbios
        retry count number

 Replace number with a number greater than 0.

 Default

 20 times

 Example

 To retransmit fifty times:

     netware netbios
        retry count 50


ΓòÉΓòÉΓòÉ 17.5.8. retry delay ΓòÉΓòÉΓòÉ

retry delay

Use this setting to specify how many milliseconds NetBIOS waits between
transmissions while establishing a connection or resending a data packet.

Syntax

     netware netbios
        retry delay number

 Replace number with a number of milliseconds greater than 0.

 Default

 500 milliseconds

 Example

 To wait eight hundred milliseconds between retransmission attempts:

     netware netbios
        retry delay 800


ΓòÉΓòÉΓòÉ 17.5.9. sessions ΓòÉΓòÉΓòÉ

sessions

Use this setting to specify how many simultaneous NetBIOS sessions can be
supported by the NetBIOS driver.

Syntax

     netware netbios
        sessions number

 Replace number with a number of sessions from 4 to 64.

 Default

 16 sessions

 Example

 To allow one hundred NetBIOS sessions:

     netware netbios
        sessions 50


ΓòÉΓòÉΓòÉ 17.5.10. Bind ΓòÉΓòÉΓòÉ

Bind

Use this setting to specify the primary NetBIOS netowrk board in your
workstaion.

NetBIOS uses its primary board to manage NetBIOS names. You can only configure
one primary NetBIOS network board.

Syntax

     netware netbios
        bind board_number

 Replace board_number with the logical board number of a network board.
 Board_number can be a value from 1 to 16.

 Logical board numbers are assigned in ascending order to each frame type as
 they appear in your configuration.

 Note that logical board numbers are assigned to default frame types.

 The board_number given must be the logical board number of a frame type used
 by IPX.

 Note: You specify IPX usage of a frame type by using the protocol setting
 under the link driver option.

 Default

 NetBIOS uses IPX's primary baord as its own primary board when the bind
 setting is not specified, out of range, or if the board_number given does not
 match the logical board number of a frame type in use by IPX.

 Example

 Configure NetBIOS as follows in order to use the logical board defined by the
 NE2000 link driver and the Ethernet 802.3 frame type as the NetBIOS primary
 network board:

 Link Driver NE2T
     Frame Ethernet_802.2;logical board 1
     Frame Ethernet_II;logical board 2
     Protocol IPX 0 Ethernet_802.2
     Protocol IP 800 Ethernet_II

 Link Driver NE2000
     Frame Ethernet_802.3;logical board 3
     Protocol IPX 0 Ethernet_802.3

 netware netbios
     bind 3


ΓòÉΓòÉΓòÉ 17.6. NetWare Requester ΓòÉΓòÉΓòÉ

NetWare Requester

Use this option to control network requests from your workstation to a NetWare
server.

Syntax

     netware requester
        cache buffers number
        default login drive driveletter
        display hard errors off
        large internet packets off
        name context "context"
        packet burst off
        preferred server servername
        preferred tree treename
        request retries number
        sessions number
        signature level number


ΓòÉΓòÉΓòÉ 17.6.1. cache buffers ΓòÉΓòÉΓòÉ

cache buffers

Use this setting to specify how many buffers NetWare Client for OS/2 can use to
cache data from open files.

Cache buffers minimize read and write traffic on the network. The more buffers,
the faster NetWare Client for OS/2 performs; however, more buffers use up more
memory.

NetWare Client for OS/2 automatically uses the maximum buffer size permitted by
each server to which NetWare Client for OS/2 is connected. However, NetWare
Client for OS/2 cannot use more than 64 KB of total memory for cache buffers,
so if the buffer size is large, you may not be allowed as many buffers as you
specify.

Syntax

     netware requester
        cache buffers number

 Replace number with a number of buffers from 0 to 30.

 To turn off caching, specify 0.

 Default

 8 buffers

 Example

 To allow 15 cache buffers:

     netware requester
        cache buffers 15


ΓòÉΓòÉΓòÉ 17.6.2. large internet packets off ΓòÉΓòÉΓòÉ

Large Internet Packets Off

Use this setting to disable large internet packets transmission. Improving
Speed and Security explains more about large internet packets.

Syntax

     netware requester
        large internet packets off

 Type large internet packets off to turn off large packet transmissions.

 Default

 Large internet packets are transmitted.

 Example

 To disable large packet transmission:

     netware requester
        large internet packets off


ΓòÉΓòÉΓòÉ 17.6.3. default login drive ΓòÉΓòÉΓòÉ

default login drive

Use this option to change the default login drive from drive L: to another
network drive.

Syntax

     netware requester
        default login drive drive letter

 Replace drive letter with the letter of another network drive.

 If you change the default login drive setting, you must also edit the LIBPATH,
 DPATH, and PATH statements in your CONFIG.SYS file from L:\OS2 to drive
 letter:\OS2.

 Default

 drive L:

 Example

 To change your default login drive from drive L: to drive F:

     netware requester
        default login drive f

 In your CONFIG.SYS in the LIBPATH, DPATH, and PATH lines, you must change all
 references of L:\OS2 to F:\OS2.


ΓòÉΓòÉΓòÉ 17.6.4. name context ΓòÉΓòÉΓòÉ

Name Context

Use this setting to specify the workstation's name context in the directory
services tree.  Concepts explains more about name contexts.

Syntax

     netware requester
        name context context

 Replace context with your name context in the directory tree.

 Default

 At the root of the tree.

 Example

 To specify a name context:

     netware requester
        name context "john.sales.novell us"


ΓòÉΓòÉΓòÉ 17.6.5. packet burst off ΓòÉΓòÉΓòÉ

packet burst off

Use this setting to disable the packet burst feature. Improving Speed with
Packet Burst explains more about the Packet Burst feature.

Syntax

     netware requester
        packet burst off

 Default

 Packet burst is enabled.

 Example

 To disable packet burst:

     netware requester
        packet burst off


ΓòÉΓòÉΓòÉ 17.6.6. preferred server ΓòÉΓòÉΓòÉ

preferred server

Use this setting to specify which NetWare server you want your workstation to
attach to when it first accesses the network.

NoteIf the server you specify is unavailable, your workstation will attach to
the first available server.

Syntax

     netware requester
        preferred server servername

 Replace servername with the name of a server. The server you specify should
 probably have the NetWare utilities for OS/2 installed.

 Default

 None

 Example

 To attach to server FINANCE:

     netware requester
        preferred server finance


ΓòÉΓòÉΓòÉ 17.6.7. preferred tree ΓòÉΓòÉΓòÉ

preferred tree

Use this setting to specify a tree name to connect. This setting is only for
sites with more than one directory tree.

Syntax

     netware requester
        preferred tree treename

 Replace treename with the name of your tree. Tree names can have up to 32
 characters.

 Default

 None.

 Example

 To connect to a tree named Novell:

     netware requester
        preferred tree novell


ΓòÉΓòÉΓòÉ 17.6.8. request retries ΓòÉΓòÉΓòÉ

request retries

Use this setting to specify how many times NetWare Client for OS/2 tries to
resend a request following a communication error.

Syntax

     netware requester
        request retries number

 Replace number with a number of retries greater than 5.

 Default

 20.

 Decrease the default if you are connected to the network over a modem and you
 do not want to waste phone time while NetWare Client for OS/2 keeps trying to
 resend packets.

 Example

 To decrease the number of times NetWare Client for OS/2 tries to resend a
 packet:

     netware requester
        request retries 10


ΓòÉΓòÉΓòÉ 17.6.9. sessions ΓòÉΓòÉΓòÉ

sessions

Use this setting to specify the number of connections NetWare Client for OS/2
can have to all servers.

Syntax

     netware requester
        sessions number

 Replace number with a number of connections from 8 to 32.  You must have at
 least three IPX sockets for each session you allow. See sockets

 Default

 8 sessions

 Example

 To allow more server connections:

     netware requester
        sessions 20

 You must also increase the sockets setting for the Protocol Stack IPX option
 in this case.


ΓòÉΓòÉΓòÉ 17.6.10. signature level ΓòÉΓòÉΓòÉ

signature level

Use this setting to assign a signature level. Signature levels help determine
security on your network. Improving Security by Using NCP Packet Signature
explains more about signature levels.

Syntax

     netware requester
        signature level number

 Replace number with 0, 1, 2, or 3.

 List of NCP Packet Signature levels

 Number    Explanation

 0         Workstation does not sign packets

 1         Workstation signs packets only if the server requests it (server
           option is 2 or higher)

 2         Workstation signs packets if the server is capable of signing
           (server option is 1 or higher)

 3         Workstation signs packets and requires the server to sign packets
           (or logging in will fail)

 Default

 1 (Workstation signs packets only if the server requests signing.)

 Example

 To prevent the workstation from signing packets:

     netware requester
        signature level 0


ΓòÉΓòÉΓòÉ 17.6.11. display hard errors ΓòÉΓòÉΓòÉ

display hard errors

Use this option to keep programs running without interaction when a hard error
is displayed. With this option set, hard errors are automatically returned to
the program that caused them rather than displayed to you for further
interaction.

This option is useful for sites with unattended workstations. Be careful about
using it in other environments as you might turn off important messages.

NoteHard errors display on a full screen and prompt you to choose among several
actions. These error messages cause background processes to suspend until you
respond to the message.

Syntax

     netware requester
        display hard errors off

 To display error messages, leave this line out of your NET.CFG file.

 Default

 Error messages are displayed.

 Example

 To prevent hard error messages from displaying:

     netware requester
        display hard errors off


ΓòÉΓòÉΓòÉ 17.7. Protocol ODINSUP ΓòÉΓòÉΓòÉ

Protocol ODINSUP

Use this option to allow the NDIS protocol stack (used with Extended Services
and LAN Services) to communicate using ODI Token-Ring or Ethernet drivers. See
Using ODINSUP and LANSUP before using this option.

Syntax

 protocol odinsup
     bind driver [number]

 Use this setting to bind the ODINSUP protocol to an ODI driver. When ODINSUP
 is bound to a driver, the network board for that driver is the board used for
 transmissions to and from the network.

 Replace driver with a Token-Ring or Ethernet ODI driver name. See List of
 Network Boards and Drivers for a list of common driver names.

 Use number to bind ODINSUP to a particular occurrence of a board when you have
 two boards with the same name. Replace number with a number from 1 to 4.

 For example, if you have two NE2000 network boards in your workstation, bind
 ODINSUP to each board by typing a 2 for the second board.

 ODINSUP can be bound to a maximum of four ODI drivers.

 Default

 ODINSUP binds to the first Ethernet or Token-Ring board it locates.

 Examples

 To bind ODINSUP to a single NE2000 board in your workstation:

 protocol ODINSUP
     bind ne2000

 To bind ODINSUP to both the first and the second NE2000 boards in your
 workstation:

 Protocol ODINSUP
     bind ne2000
     bind ne2000 2


ΓòÉΓòÉΓòÉ 17.8. Protocol Stack IPX ΓòÉΓòÉΓòÉ

Protocol Stack IPX

Use this option to adjust IPX communication between applications and the LAN
drivers in your workstation.

Syntax

 protocol stack ipx
     bind name
     router mem size
     sockets number


ΓòÉΓòÉΓòÉ 17.8.1. bind ΓòÉΓòÉΓòÉ

bind

Use this setting to specify the primary network board in your workstation. By
default, the primary board is the board whose driver loads first in the
CONFIG.SYS file. If you specify a different board with this setting, that
default is changed. See Network Boards and Drivers.

Syntax

 protocol stack ipx
     bind name

 Replace name with the driver name for your network board. List of Network
 Boards and Drivers lists common network boards.

 Default

 The first driver listed in your CONFIG.SYS file.

 Example

 To specify a 3Com Etherlink 3C503 board as primary:

 protocol stack ipx
     bind 3C503


ΓòÉΓòÉΓòÉ 17.8.2. router mem ΓòÉΓòÉΓòÉ

router mem

Use this setting to specify how many bytes in the router memory pool are
allocated for routing requests to the network.

Syntax

 protocol stack ipx
     router mem size

 Replace size with a number of bytes.

 Default

 450 bytes

 Since a size of 450 bytes accommodates up to 15 network boards per
 workstation, you should not need to increase this default.

 Example

 To increase the default:

 protocol stack ipx
     router mem 500


ΓòÉΓòÉΓòÉ 17.8.3. sockets ΓòÉΓòÉΓòÉ

sockets

Use this setting to specify how many sockets IPX can open at your workstation.

Syntax

 protocol stack ipx
     sockets number

 Replace number with a number of sockets between 9 and 128. If you are running
 IPX with NetWare Client for OS/2 do not set this value below 32.

 You need three sockets per server connection. The default of 64 works for the
 default number of server connections. See sessions.

 Allow more sockets if your workstation connects to many different servers or
 runs protocols (such as Named Pipes) that require sockets.

 Default

 64 sockets

 Example

 To set the socket limit for a workstation connected to several servers that is
 running Named Pipes and applications that require sockets:

 protocol stack ipx
     sockets 128


ΓòÉΓòÉΓòÉ 17.9. Protocol Stack SPX ΓòÉΓòÉΓòÉ

Protocol Stack SPX

Use this option to adjust the number and characteristics of SPX connections
between your workstation and other computers.

Syntax

 protocol stack spx
     abort timeout number
     listen timeout number
     retry count number
     send timeout number
     sessions number
     verify timeout number


ΓòÉΓòÉΓòÉ 17.9.1. Abort, Listen, and Verify Timeouts ΓòÉΓòÉΓòÉ

Abort timeout, Listen timeout and Verify timeout

Use these settings to monitor and control SPX connections.

When SPX sessions at a sending computer do not receive transmissions from the
receiving computer for the length of the "verify timeout" interval, SPX sends a
keep-connection-alive packet to the receiving computer. SPX then waits the
length of the "listen timeout" interval to receive a response.

If no response is received, SPX sends another packet requesting immediate
acknowledgment. SPX then waits the length of the "abort timeout" interval to
receive a response.

If no response is received, SPX aborts the session.

Syntax

 protocol stack spx
     abort timeout number
     listen timeout number
     verify timeout number

 Replace number with a number of milliseconds greater than 10.

 The ratio between these settings must remain the same. For example, if you
 double the Listen timeout value, you must also double the Abort timeout and
 Verify timeout values.

 If the machine you are setting up will be a Named Pipes server, double the
 default timeout values.

 Default

 Abort timeout: 30,000 milliseconds

 Listen timeout: 6,000 milliseconds

 Verify timeout: 3,000 milliseconds

 Example

 To make SPX wait longer before sending a keep-connection-alive packet, sending
 the packet requesting immediate response, or aborting the session:

 protocol stack spx
     abort timeout 40000
     listen timeout 8000
     verify timeout 4000


ΓòÉΓòÉΓòÉ 17.9.2. Retry Count ΓòÉΓòÉΓòÉ

Retry Count

Use this setting to specify the number of times your workstation will resend
packets that weren't acknowledged by the receiving computer the first time they
were sent.

NoteSome applications may set the "retry count" value. In these cases, the
application-set value is used and the NET.CFG value is ignored.

Syntax

 protocol stack spx
     retry count number

 Replace number with a number of retries from 1 to 255.

 If your network traffic is heavy or if you are transmitting across routers,
 you may want to increase the default.

 Default

 12 retries

 Example

 To increase the number of times packets are resent:

 protocol stack spx
     retry count 30


ΓòÉΓòÉΓòÉ 17.9.3. Send Timeout ΓòÉΓòÉΓòÉ

Send Timeout

Use this setting to specify how long SPX waits between attempts to send packets
across the network.

Syntax

 protocol stack spx
     send timeout number

 Replace number with a number of milliseconds greater than 500.

 This default works well in almost all cases. Increase the default if you are
 using network management products with a very large network and you encounter
 many SPX connection errors.

 You may also want to increase the default for a Named Pipes client that is
 operating faster than the Named Pipes server to which it is connected.

 Default

 A continually calculated value based on the time it takes SPX to get a
 response from the server.

 Example

 To increase the wait between sends:

 protocol stack spx
     send timeout 5600


ΓòÉΓòÉΓòÉ 17.9.4. Sessions ΓòÉΓòÉΓòÉ

Sessions

Use this setting to specify how many SPX connections can be open
simultaneously.

Syntax

 protocol stack spx
     sessions number

 Replace number with a number of SPX connections greater than 8. Numbers higher
 than 1,000 may not work in all circumstances.

 If you run Named Pipes applications or other applications that use SPX, you
 may need to increase the default number of sessions.

 Default

 16 sessions

 Example

 To increase the number of SPX sessions:

 protocol stack spx
     sessions 64


ΓòÉΓòÉΓòÉ 17.10. Token-Ring Source-Route Driver ΓòÉΓòÉΓòÉ

Token-Ring Source-Route Driver

Use this option to configure the Requester for source-routing between
Token-Ring networks that are connected with source routers. For more
information about source routing, see Using OS/2 Workstations on a Token-Ring
Network.

NoteDo not use this option if your Token-Ring networks do not use source
routing.

Syntax

 protocol route
     source route def gbr mbr nodes n board n

 board

 Use this setting to specify the logical board (frame) of a particular type
 that is performing source routing.

 Syntax

 protocol route
     source route board n

 Replace n with a logical board (frame) number from 1 to 16.

 For example, if a workstation has more than one frame type listed in the Link
 Driver option, by default only the first listed frame is source routed. To
 enable source routing on the second or other frames, you must explicitly
 specify the second frame as logical board 2.

 Default

 1

 Example

 To specify that logical board 2, the Token-Ring_SNAP frame, will also be
 source routed:

 link driver token
     frame token-ring
     frame token-ring_snap
     protocol route
     source route board 1
     source route board 2

 DEF

 Use this setting (default frame) to prevent frames that have unknown
 destination addresses from being sent across Single Route IBM bridges.

  If this setting is specified, these frames are forwarded as All Routes
 Broadcast frames.

  If this setting is not specified, all frames that have addresses not in the
 workstation's Source Routing table are forwarded as Single Route Broadcast
 frames.

  If ROUTE.SYS has already been configured with the DEF setting, reloading
 ROUTE.SYS with this setting broadcasts all subsequent Single Route Broadcast
 frames as All Routes Broadcast frames.

 Syntax

 protocol route
     source route def

 Type DEF to broadcast on all routes. Omit DEF to broadcast on a single route
 only.

 Default

 DEF is omitted (single-route broadcast only)

 Change this default when you are unsure of the stability of one or more routes
 in the network. Be aware that using DEF will substantially increase network
 traffic, especially on large, redundant ring networks.

 Example

 To broadcast on all routes:

 protocol route
     source route def

 GBR

 Use this setting (general broadcast) to specify that all General Broadcast
 frames are to be sent as All Routes Broadcast frames.

 Syntax

 protocol route
     source route gbr

 Type GBR to broadcast to all destinations, on all rings, by all routes. Omit
 GBR to broadcast to all destinations, on all rings, by a single route.

 Change the default when you want to ensure successful transmission across all
 possible routes. If ROUTE has already been configured with this setting,
 reconfiguring ROUTE with this setting broadcasts all subsequent General
 Broadcast frames as All Routes Broadcast frames.

 Default

 GBR is omitted (single route broadcast only)

 Example

 To broadcast to all destinations, on all rings, by all routes:

 protocol route
     source route gbr

 MBR

 Use this setting (multicast) to specify that all Multicast Broadcast frames
 are to be sent as All Routes Broadcast frames.

 Syntax

 protocol route
     source route mbr

 Type MBR to transmit multicast frames simultaneously to a group of
 destinations by all possible routes. Omit MBR to transmit multicast frames by
 a single route.

 Default

 MBR is omitted (transmit by single route only)

 If ROUTE has already been configured with the MBR setting, reconfiguring ROUTE
 with this parameter broadcasts all subsequent Multicast Broadcast frames as
 All Routes Broadcast frames.

 Example

 To broadcast multicast frames simultaneously:

 protocol route
     source route mbr

 nodes

 Use this setting to specify the number of table entries in the source-routing
 table.

 Syntax

 protocol route
     source route nodes n

 Replace n with a number of table entries from 8 to 255. If you type a number
 less than 8, 8 will be used.

 Default

 16 entries

 Example

 To allow twenty-four entries in the source-routing table:

 protocol route
     source route nodes 24


ΓòÉΓòÉΓòÉ 18. System Messages ΓòÉΓòÉΓòÉ

System Messages

This section includes system messages and explanations for all NetWare Client
for OS/2 drivers and daemons. Messages for the NetWare Tools or the Network
Printer (NPRINTER.EXE) programs are not included. For information about
messages for those modules, see the System Messages manual.

REQ0106: An error occurred during attempt to get shared memory.

 Explanation    DDAEMON.EXE attempted to access the daemon's shared memory, but
                failed. At this point, the program has verified that the shared
                memory exists, but is unable to access it. This may be an
                internal program error.
 Action         Try rebooting your system. If the problem persists, call your
                Novell Authorized Reseller.

 REQ0107: An error occurred during attempt to allocate a shared segment.

 Explanation    DDAEMON.EXE tried to create shared memory, but none is
                available. This error usually occurs when the device drivers
                and applications currently running on your system require more
                memory than your system has available.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0108: The daemon cannot access the Link Support Layer. Error: <code>.

 Explanation    DDAEMON.EXE cannot find the Link Support device driver LSL.SYS.
 Action         Make sure that the device driver LSL.SYS has been properly
                entered in the CONFIG.SYS file. If so, check the messages
                displayed by the LSL for any errors or warnings, and correct
                the problems indicated. Try again. If this error persists, call
                your Novell Authorized Reseller.

 REQ0109: The DDAEMON is already loaded.

 Explanation    DDAEMON.EXE tried to create shared memory for the first time,
                but the memory already exists. Another daemon is already
                running. The attempt to create shared memory is terminated.
 Action         Make sure that you are not trying to run multiple copies of the
                daemon. Typically the daemon is run from the CONFIG.SYS file at
                system startup and does not need to be executed again.

 REQ0204: The system does not have enough memory for socket tables.

 Explanation    OS/2 lacks sufficient system memory for IPX to allocate memory
                for its socket tables.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0205: The LAN support module could not be installed.

 Explanation    Either the LSL.SYS driver failed to load, or the "DEVICE="
                statement is missing from the CONFIG.SYS file.
 Action         Either correct the problem that kept the LSL.SYS driver from
                loading (indicated in an error message preceding this one), or
                add the "DEVICE=" statement to the CONFIG.SYS file.

 REQ0206: The IPX MLID could not be installed.

 Explanation    Either the Multiple Link Interface Driver (MLID) specified in
                the CONFIG.SYS failed to load, or the "DEVICE=" statement for
                an MLID is missing from the CONFIG.SYS file.
 Action         Either correct the problem that kept the MLID from loading
                (indicated in an error message preceding this one), or add the
                "DEVICE=" statement to the CONFIG.SYS file.

 REQ0207: The configured LAN-A driver does not support IPX.

 Explanation    The Multiple Link Interface Driver (MLID) to which IPX.SYS
                attempted to bind does not support IPX-based data
                transmissions.
 Action         Bind IPX to an MLID that supports IPX-based data transmissions.

 REQ0208: The IPX protocol handler cannot be registered.

 Explanation    IPX cannot register with the LSL.SYS driver because the LSL is
                servicing its maximum number of protocol stacks.
 Action         Remove the "DEVICE=" statements for any unnecessary protocol
                stacks from the CONFIG.SYS file.

 REQ0209: The IPX entry point cannot be initialized.

 Explanation    The IPX and link support layer (LSL) versions may not be
                compatible versions.
 Action         Make sure that the IPX.SYS driver and LSL.SYS driver are
                compatible. If they are not, obtain compatible drivers from
                your Novell Authorized Reseller. If this is not the problem,
                contact your Novell Authorized Reseller for customer
                assistance.

 REQ0210: An internal error occurred. The IPX router socket cannot be opened.

 Explanation    IPX was unable to open the router socket due to an internal
                program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0211: An internal error occurred. A router selector cannot be allocated.

 Explanation    IPX was unable to allocate an OS/2 router selector due to an
                internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0212: The system has insufficient memory to allocate a router.

 Explanation    OS/2 cannot access sufficient system memory for IPX routing
                purposes.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0213: Router memory is exhausted.

 Explanation    IPX did not have enough memory previously allocated for routing
                purposes.
 Action         Increase the size of the IPX router memory in the NET.CFG
                "ROUTER MEM" statement.

 REQ0214: An internal error prevented CGroup variable initialization.

 Explanation    An internal program error has occurred. IPX was unable to
                initialize internal variables.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0215: An internal error prevented DosHlp variable initialization.

 Explanation    OS/2 internal variables were either incomplete or invalid.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0216: IPX cannot register with OS/2 for PDD-to-VDD communications.

 Explanation    This is an internal program error. IPX cannot register with
                OS/2 for VIPX.SYS driver support.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0217: The IPX device driver is not running.

 Explanation    Either IPX.SYS encountered a fatal error during system
                initialization, or the "DEVICE=[path]IPX.SYS" statement was
                missing from the CONFIG.SYS file. If the problem is a fatal
                error, another message should precede this one that identifies
                the specific error that occurred.
 Action         Either resolve the fatal problem (indicated in a preceding
                message), or add the "DEVICE=" statement to the CONFIG.SYS
                file; then try again. If the problem persists, contact your
                Novell Authorized Reseller.

 REQ0231: The default protocol configuration option is not used for IPX.

 Explanation    IPX cannot be configured as a default protocol stack.
 Action         Remove this option statement from the NET.CFG file.

 REQ0232: The prescan protocol configuration option is not used for IPX.

 Explanation    IPX cannot be configured as a prescan protocol stack.
 Action         Remove this option statement from the NET.CFG file.

 REQ0233: The OS/2 version number cannot be found; OS/2 v2.0 is assumed.

 Explanation    IPX's query of OS/2 for the version number returned a value
                that did not match the value it expected to receive.
 Action         Make sure the OS/2 version installed on the machine is v2.0 or
                later.

 REQ0304: An LSL error occurred. NET.CFG buffers are too big for ECB pool.

 Explanation    The configured buffer size for the Link Support component is
                too large. Total available buffer space is around 60 KB, but
                the Link Support Layer (LSL) is unable to allocate even one
                buffer of the requested size in its buffer space. See "Link
                Support Layer" in Concepts for more information about LSL.
 Action         Reduce the Link Support component's buffer size in the NET.CFG
                file. It is more important to have several smaller buffers
                available than one large one. It is a waste of system memory to
                configure buffers much larger than the communications media can
                support.

 REQ0305: The Link Support module (LSL) could not install the AES timer.

 Explanation    The Link Support Layer (LSL) could not register its timer
                handler with the operating system because the maximum number of
                handlers have already been installed. This timer handler is a
                critical component of the Requester, and none of the
                Novell-supplied communication handlers can be expected to work
                properly without it. See "Link Support Layer" in Concepts for
                more information about LSL.
 Action         Previously installed device drivers (those entered before
                LSL.SYS in the CONFIG.SYS file) have used all available timer
                resources. Identify those device drivers and either remove or
                reconfigure them. Since the Requestor's communications handlers
                all use a common timer service in the LSL, only one available
                timer handler is required for proper operation. If you are
                unable to resolve this problem, contact your Novell Authorized
                Reseller.

 REQ0306: The Link Support module could not initialize its call gate.

 Explanation    The Link Support module could not register its entry point with
                the operating system. This entry point is vital to most of the
                Requester's communications components, and its absence will
                cause them to fail. The most likely cause of this error is a
                previously loaded device driver that is using too many kernel
                resources.
 Action         Try removing application device drivers installed before
                LSL.SYS in the CONFIG.SYS file. It is highly unlikely that a
                device driver from the OS/2 base system has caused this error.
                If the problem persists, contact your Novell Authorized
                Reseller.

 REQ0404: NetBIOS error occurred. Link Support module cannot be installed.

 Explanation    NetBIOS could not open or communicate with the Link Support
                LINKSUP_ device driver. This can happen if the Link Support
                Layer (LSL) driver has not been properly installed or if you
                are using the wrong version of the driver. See "Link Support
                Layer" in Concepts for more information about LSL.
 Action         Make sure that the device driver LSL.SYS has been properly
                entered in the CONFIG.SYS file. If so, check the messages
                displayed by the LSL for any errors or warnings, and correct
                the problems indicated. If the Link Support device driver is
                initializing properly, the problem is with incompatible
                versions of the software. NetBIOS and Link Support are usually
                installed together from a single installation diskette. Try
                reinstalling them. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0405: NetBIOS error occurred. The IPX module is not installed.

 Explanation    NetBIOS could not open or communicate with the Link Support
                LINKSUP_ device driver. This can happen if the Link Support
                Layer (LSL) driver has not been properly installed or if you
                are using the wrong version of the driver. See "Link Support
                Layer" in Concepts for more information about LSL.
 Action         Make sure that the device driver LSL.SYS has been properly
                entered in the CONFIG.SYS file. If so, check the messages
                displayed by the LSL for any errors or warnings, and correct
                the problems indicated. If the Link Support device driver is
                initializing properly, the problem is with incompatible
                versions of the software. NetBIOS and Link Support are usually
                installed together from a single installation diskette. Try
                reinstalling them. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0406: The NetBIOS call gate cannot be initialized.

 Explanation    This is an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0407: NetBIOS error occurred. The program cannot initialize local NCBs.

 Explanation    Insufficient memory is available for the NCBs requested.
                Usually this error is caused by incorrect configuration
                information in the NET.CFG file. However, the underlying
                problem could also be a lack of global system resources in the
                OS/2 Global Descriptor Table.
 Action         Reduce the number of commands in the NetBIOS section of the
                CONFIG.SYS file. (The default number of commands is 12; the
                maximum allowed is 25.) You also might be able to reduce the
                number of node names (possible range is 0-126). Additional
                possibilities include adding RAM, reducing your configuration
                options (for example, reducing the size of DIRCACHE) or
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2 and then reboot the system. If the problem persists,
                contact your Novell Authorized Reseller.

 REQ0408: NetBIOS emulator parameters are too large for the memory pool.

 Explanation    Insufficient memory is available for all of the control tables
                needed by the NetBIOS emulator.
 Action         The amount of table space available to the NetBIOS emulator
                cannot be increased. The only way to solve this problem is to
                reduce the number of NetBIOS resources you are requesting. You
                can do this by modifying the NETBIOS parameters in the NET.CFG
                file. If the problem persists, contact your Novell Authorized
                Reseller.

 REQ0409: Incompatible versions of OS/2 and NetBIOS are running.

 Explanation    You are attempting to run NetBIOS v2.10 on some version of OS/2
                earlier than OS/2 v2.1.
 Action         Either install OS/2 v2.1 to run with NetBIOS v2.10, or install
                a different version of NetWare NetBIOS to match your OS/2
                version.

 REQ0504: The SPX module is not installed.

 Explanation    The NMPIPE.SYS driver could not open or communicate with the
                SPX.SYS driver.
 Action         Make sure that the SPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated; then try again. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0505: The IPX module is not installed.

 Explanation    NMPIPE.SYS could not open or communicate with the IPX.SYS
                driver.
 Action         Make sure that the IPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated; then try again. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0519: An incorrect OS/2 version is being used.

 Explanation    Either the DosGetVersion call failed (an internal program
                error), or the OS/2 version currently running is not v2.0 or
                later.
 Action         Make sure the client OS and NMPIPE.SYS driver are compatible
                versions. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0520: The driver cannot register the PDD for VDD-to-PDD communications.

 Explanation    NMPIPE.SYS could not register IPX as a PDD so that PDD to VDD
                communication may take place.
 Action         Make sure the IPX.SYS driver has been properly entered in the
                CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Also make sure the OS/2 version is v2.0 or later;
                then try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0613: Invalid characters were specified in COMPUTERNAME.

 Explanation    The Named Pipes server name specified after NPDAEMON.EXE is
                invalid.
 Action         Make sure the server name is not more than 15 characters and is
                composed of letters, numbers, and these special characters:
                !#$%&()-.@^_Γö┤{}~

 REQ0614: An error occurred during attempt to initialize NPCALLS.DLL.

 Explanation    The NPDaemon could not initialize NPCALLS.DLL.
 Action         Make sure the NPCALLS.DLL file in the NetWare Requester
                directory is included in the LIBPATH statement of the
                CONFIG.SYS file. If you are running Named Pipes, make sure the
                NMPIPE.SYS driver and NPSERVER.SYS are correctly configured in
                the CONFIG.SYS file.

 REQ0615: The Named Pipes daemon could not be registered. Error:  <code>.

 Explanation    The NPDaemon could not open or communicate with the NMPIPE.SYS
                driver.
 Action         Make sure the NMPIPE.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems.
                Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0616: An error occurred during attempt to allocate shared memory.

 Explanation    The NPDaemon could not allocate shared memory.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0617: An error occurred during attempt to allocate the ECB pool.

 Explanation    The NPDaemon could not allocate memory for the ECB pool.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0618: An error occurred during attempt to create a system semaphore.

 Explanation    A DosCreateSem call failed. An internal program error may have
                occurred.
 Action         Try again. If the error persists, contact your Novell
                Authorized Reseller.

 REQ0619: An error occurred during attempt to create a thread.

 Explanation    A beginthread call failed. An internal program error may have
                occurred.
 Action         Try again. If the error persists, contact your Novell
                Authorized Reseller.

 REQ0620: A dynamic socket could not be opened. Error: <code>.

 Explanation    The NPDaemon failed to open a dynamic socket.
 Action         Increase the socket count specified in the NET.CFG file; then
                reboot the system and try again. If the problem persists,
                contact your Novell Authorized Reseller.

 REQ0621: A well-known socket could not be opened. Error: <code>.

 Explanation    The NPDaemon could not open Netware's registered Named Pipe
                socket; the socket may already be in use.
 Action         Increase the SPX socket count in the NET.CFG and shut down
                OS/2; then reboot the system.

 REQ0622: The NPDaemon cannot get the internet address. Error: <code>.

 Explanation    An IpxGetInternetworkAddress call failed.
 Action         Make sure the IPX.SYS driver has been properly entered in the
                CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Also make sure the IPXCALLS.DLL file is in the
                NetWare Requester directory; then try again. If the problem
                persists, notify your Novell Authorized Reseller.

 REQ0623: The NPDaemon cannot get the local target. Error: <code>.

 Explanation    An IpxGetLocalTarget call failed.
 Action         Make sure the IPX.SYS driver has been properly entered in the
                CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Also make sure the IPXCALLS.DLL file is in the
                NetWare Requester directory; then try again. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ0624: The service advertising function failed. Error: <code>.

 Explanation    An IpxSend call to advertise this workstation as Named Pipe
                Server failed.
 Action         Make sure the IPX.SYS driver has been properly entered in the
                CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Also make sure the IPXCALLS.DLL file is in the
                NetWare Requester directory; the try again. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ0625: The broadcast socket cannot be opened. Error: <code>.

 Explanation    The broadcast socket cannot be opened. This is a registered
                socket by which SAPs can be received. Possibly this socket has
                already been opened.
 Action         Increase the socket count in the NET.CFG file and shut down
                OS/2 and then reboot the system. If the problem persists,
                contact your Novell Authorized Reseller.

 REQ0626: An error occurred during attempt to get code page information.

 Explanation    A call to DosGetCtryInfo failed. This may be an internal
                program error.
 Action         Make sure the OS/2 is version 2.0 or later. If so, and the
                problem persists, contact your Novell Authorized Reseller.

 REQ0628: Memory cannot be allocated for turbo buffers.

 Explanation    The NPDaemon could not allocate memory for turbo buffers.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0629: A connection thread died abnormally. Error:  <code>.

 Explanation    The connection controller thread died unexpectedly.
 Action         Make sure that the SPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Also make sure all of your Named Pipe drivers are
                within the same major version (for example, v2.x); then try
                again. If the problem persists, contact your Novell Authorized
                Reseller.

 REQ0630: The specified computer name is already registered on the internet.

 Explanation    The Named Pipes server name specified in the CONFIG.SYS file
                has already been used on the network.
 Action         Use a different server name.

 REQ0631: The receive buffer manager died abnormally. Error: <code>.

 Explanation    The receive buffer manager thread died unexpectedly.
 Action         Make sure that your Named Pipes drivers are within the same
                major version (for example, v2.x). If so, try adding RAM,
                reducing your configuration options in the CONFIG.SYS file (for
                example, reducing the size of DIRCACHE), removing optional
                device drivers from the CONFIG.SYS file, and freeing up some
                hard disk space by deleting unnecessary programs. If you are
                using multiple disk partitions, consider moving the OS/2
                swapper file to a larger partition. Disk compression utilities
                may also be available that can help resolve this problem. After
                completing these actions, shut down OS/2; then reboot the
                system. If the problem persists, contact your Novell Authorized
                Reseller.

 REQ0635: General Service Query for Named Pipe Servers failed. Error: %1 %0

 Explanation    A call to IpxSend to issue a general service query for named
                Pipe Servers failed.
 Action         Make sure the IPX.SYS driver has been properly entered in the
                CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Also make sure the IPXCALLS.DLL file is in the
                NetWare Requester directory.Try again. If the problem persists,
                contact your Novell authorized reseller.

 REQ0636: An error occurred while obtaining the IPX card table.%0

 Explanation    A call to the npserver.sys driver to obtain the IPX card table
                failed.
 Action         Make sure the IPX.SYS driver and the NPSERVER.SYS driver have
                been properly entered in the CONFIG.SYS file. If so, check the
                messages displayed by the drivers for any errors or warnings,
                and correct the problems indicated. Also make sure the
                IPXCALLS.DLL and NPCALLS.DLL files are in the NetWare Requester
                directory. Try again. If the problem persists, contact your
                Novell Authorized Reseller.

 REQ0704: The SPX module is not installed.

 Explanation    The Named Pipes daemon could not open or communicate with the
                SPX.SYS driver.
 Action         Make sure that the SPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated; then try again. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0705: The IPX module is not installed.

 Explanation    The Named Pipes daemon could not open or communicate with the
                IPX.SYS driver.
 Action         Make sure that the IPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated; then try again. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0719: An incorrect OS/2 version is being used.

 Explanation    The DosGetVersion call failed (which would indicate an internal
                program error) or the OS/2 version currently running is not
                v2.0 or later.
 Action         Make sure that the client OS and NMPIPE.SYS driver are
                compatible; then try again. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0806: The program cannot get code page information. Error: <code>.

 Explanation    The OS/2 system is not returning code page information. This
                may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0807: The Requester device driver and daemon are incompatible versions.

 Explanation    The most likely cause of this problem is that NWDAEMON.EXE and
                NWREQ.SYS driver were not installed from the same installation
                disk.
 Action         Install the Requester driver again, making sure it is from the
                correct installation disk.

 REQ0808: The worker DLL cannot be registered. Error:  <code>.

 Explanation    The NWWORKER.DLL could not register with the Requester. This
                may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0809: The broadcast handler cannot be registered. Error: <code>.

 Explanation    This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0810: The program cannot get system information. Error: <code>.

 Explanation    The OS/2 system is not returning system information. This may
                be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0811: The janitor thread priority cannot be set. Error: <code>.

 Explanation    The janitor thread is set to run at regular priority. The
                system had trouble setting the priority.
 Action         Ignore the error.

 REQ0812: The janitor daemon cannot be registered. Error: <code>.

 Explanation    This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0813: The program cannot get the current drive map. Error: <code>.

 Explanation    The OS/2 system is not returning the current drive map. This
                may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0814: The program cannot set the current drive map. Error: <code>.

 Explanation    The OS/2 system is not setting the current drive map. This may
                be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0815: The program cannot get the connection ID. Error: <code>.

 Explanation    The Requester tried to locate a NetWare server when it
                initialized. Either no servers are currently running or a
                cabling problem exists.
 Action         Make sure the NetWare server is running and functioning
                properly. Also make sure the OS/2 machine has a working
                connection to the network; then try again. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ0816: An error occurred during attempt to initialize the cache.

 Explanation    The caching function is not working. This may be an internal
                program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0817: The daemon could not boost the thread priority.

 Explanation    The thread is set to run at a greater priority. The system had
                trouble setting the priority.
 Action         Ignore the error.

 REQ0818: The daemon could not register the DosBox handler.

 Explanation    This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0820: Not enough memory for diagnostic daemon. Error: <code>.

 Explanation    The NWDaemon program tried to allocate memory from the system
                for the diagnostic thread to use as a stack, but the system
                returned an error.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0821: The diagnostic daemon cannot be started. Error: <code>.

 Explanation    The NWDaemon tried to start the diagnostic thread but the
                system encountered an error condition. The system may have too
                many threads already running, or this may be an internal
                program error.
 Action         Try closing other applications that are currently running. If
                the problem persists, contact your Novell Authorized Reseller.

 REQ0822: The diagnostic daemon priority cannot be changed. Error: <code>.

 Explanation    The diagnostic thread is set to run at regular priority. The
                system had trouble setting the priority.
 Action         Ignore the error.

 REQ0823: Not enough memory to start a new thread. Error: <code>.

 Explanation    The NWDaemon could not allocate memory from the system to
                create a thread for a new task.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0824: The SPX send thread cannot be started. Error: <code>.

 Explanation    This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0825: The SPX receive thread cannot be started. Error: <code>.

 Explanation    This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0826: The SFT 3 handler cannot be registered.

 Explanation    This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0827: Packet Burst cannot be initialized.

 Explanation    This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ0843: Not enough memory for a network management thread (<error code>).

 Explanation    The NWDaemon tried to allocate memory from the system for a
                thread to initialize network management, but memory was not
                available. Network management cannot be initialized.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0844: A named pipe cannot be started for network management (<error code>).

 Explanation    The NWDaemon could not allocate a named pipe. Network
                management will not be supported until the computer is
                rebooted. This error could result from a variety of causes.
                Named Pipes or SPX may not be loaded, one of your drivers may
                have opened too many Named Pipes already, you may not have
                enough memory or disk space, or it may be an internal program
                error.
 Action         Make sure that Named Pipes and SPX are loaded and that your
                system has enough memory. (If you suspect a memory problem, see
                the discussion for message 843.) After completing these
                actions, reboot the system and try again. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ0845: Not enough memory to run network management (<error code>).

 Explanation    The NWDaemon program tried to allocate memory from the system
                to run network management, but memory is not available. Network
                Management will not run until memory is available and the
                system is rebooted.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0904: The NWREQ.SYS driver is not loaded.

 Explanation    NetWare Client for OS/2 cannot be initialized until the driver
                is loaded.
 Action         Load the NWREQ.SYS driver.

 REQ0914: The program cannot allocate selectors for the workspace table.

 Explanation    All available memory selectors are being used by the system or
                by previously loaded device drivers.
 Action         Remove optional or unneeded device drivers from the CONFIG.SYS
                file and try again. If the problem persists, contact your
                Novell Authorized Reseller.

 REQ0915: The program cannot allocate memory for the workspace table.

 Explanation    All available system memory is in use. NetWare Client for OS/2
                cannot load properly.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0917: Memory is not available for the cache table. Caching is disabled.

 Explanation    All available system memory is in use by the system. NetWare
                Client for OS/2 cannot load properly.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ0919: An incorrect OS/2 version is being used.

 Explanation    The major versions of NetWare Client for OS/2 and OS/2 do not
                match.
 Action         Upgrade NetWare Client for OS/2 or OS/2.

 REQ0937: The Requester driver version does not match the IFS version.

 Explanation    NWIFS.IFS and NWREQ.SYS were not installed from the same
                installation disk.
 Action         Install NetWare Client for OS/2 again. If the problem persists,
                contact your Novell Authorized Reseller.

 REQ1005: The LAN support module is not installed.

 Explanation    NetWare Client for OS/2 driver requires the LSL.SYS driver to
                be running when it loads. Either the
                "DEVICE=C:\NETWARE\LSL.SYS" line is missing from the CONFIG.SYS
                file or the LSL encountered an error while loading.
 Action         Check the CONFIG.SYS file for the LSL.SYS driver. If this is
                not the problem, contact your Novell Authorized Reseller.

 REQ1008: A NetWare server cannot be found.

 Explanation    NetWare Client for OS/2 tries to locate a NetWare server when
                it initializes. Either no servers are currently running or
                there is a cabling problem.
 Action         Make sure that the NetWare server is running and operating
                properly. Also make sure that the OS/2 machine is connected to
                the network.

 REQ1010: The program cannot allocate selectors for the connection table.

 Explanation    All available memory selectors are being used by the system or
                by previously loaded device drivers.
 Action         Remove optional or unneeded device drivers from the CONFIG.SYS
                file and try again. If the problem persists, contact your
                Novell Authorized Reseller.

 REQ1011: The program cannot allocate memory for the connection table.

 Explanation    All available system memory is in use. NetWare Client for OS/2
                cannot load properly.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system.If the problem persists, contact
                your Novell Authorized Reseller.

 REQ1019: An incorrect OS/2 version is being used.

 Explanation    The major version of NetWare Client for OS/2 and OS/2 do not
                match.
 Action         Upgrade NetWare Client for OS/2 or OS/2.

 REQ1021: The config file cannot be parsed. Default parameters will be used.

 Explanation    NetWare Client for OS/2 driver could not read parameters in the
                NET.CFG file.
 Action         Make sure the syntax for the NetWare Requester section of the
                file is correct.

 REQ1022: An unrecoverable error occurred. The driver was not loaded.

 Explanation    The driver could not load properly. This is probably an
                internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1024: The program cannot allocate selectors for worker support.

 Explanation    All available memory selectors are being used by the system or
                by previously loaded device drivers.
 Action         Remove optional or unneeded device drivers from the CONFIG.SYS
                file. Then try again. If the problem persists, contact your
                Novell Authorized Reseller.

 REQ1038: The program cannot allocate memory for the error message buffer.

 Explanation    All available system memory is in use by the system. NetWare
                Client for OS/2 cannot load properly.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ1039: The Requester could not send to NetWare server <number> as <number>.

 Explanation    NetWare Client for OS/2 waits for a response from the server
                after each request. If the server does not respond within a
                certain amount of time, NetWare Client for OS/2 times out.
 Action         Make sure that the server is still running and functioning
                properly. Also make sure that all routers between the
                workstation and the server are still running. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ1040: The Requester timed out waiting for reply from server <number>.

 Explanation    NetWare Client for OS/2 waits for a response from the server
                after each request. If the server does not respond within a
                certain amount of time, NetWare Client for OS/2 times out.
 Action         Make sure that the server is still running and functioning
                properly. Also make sure that all routers between the
                workstation and the server are still running. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ1041: Server <number> did not respond to a request.

 Explanation    NetWare Client for OS/2 waits for a response from the server
                after each request. If the server does not respond within a
                certain amount of time, NetWare Client for OS/2 times out. This
                error can also occur if the server responds with an unexpected
                response.
 Action         Make sure that the server is still running and functioning
                properly. Also make sure that all routers between the
                workstation and the server are still running. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ1042: Connection to NetWare server <number> as <number> is now invalid.

 Explanation    NetWare Client for OS/2 waits for a response from the server
                after each request. If the server does not respond within a
                certain amount of time, NetWare Client for OS/2 times out.
 Action         Make sure that the server is still running and functioning
                properly. Also make sure that all routers between the
                workstation and the server are still running. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ1043: Routing to NetWare server <number>  has been disrupted.

 Explanation    The network route to the server has been disrupted.
 Action         Make sure that the server is still running and functioning
                properly. Also make sure that all routers between the
                workstation and the server are still running. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ1045: Routing to NetWare server <number>  has been disrupted.

 Explanation    The network route to the server has been disrupted.
 Action         Make sure that the server is still running and functioning
                properly. Also make sure that all routers between the
                workstation and the server are still running. If the problem
                persists, contact your Novell Authorized Reseller.

 REQ1106: The SPDaemon cannot get the SPX version. Error:  <code>.

 Explanation    The SpxGetVersion call failed. This may be an internal program
                error.
 Action         Make sure that the SPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Check for a mismatch of driver versions. If the
                problem persists, contact your Novell Authorized Reseller.

 REQ1107: The SPX driver and the SPX daemon are incompatible versions.

 Explanation    The SPX.SYS driver and SPDAEMON.EXE versions may not match.
 Action         Make sure that the client SPX.SYS driver and SPDAEMON.EXE are
                compatible versions. If the problem persists, contact your
                Novell Authorized Reseller.

 REQ1108: The SPX driver entry cannot be obtained. Error: <code>.

 Explanation    The SPDaemon could not get a handle to the SPX.SYS driver. This
                may be an internal program error.
 Action         Make sure that the client SPX.SYS driver and SPDAEMON.EXE
                versions are compatible. If the problem persists, contact your
                Novell Authorized Reseller.

 REQ1109: The SPX daemon is already loaded. Error:  <code>.

 Explanation    The SPDAEMON.EXE has already registered with the SPX.SYS
                driver, which means it is already loaded.
 Action         Make sure that the daemon SPDAEMON.EXE has not been entered in
                the CONFIG.SYS file more than once.

 REQ1110: The daemon cannot register with the SPX driver. Error: <code>.

 Explanation    The SPDaemon cannot communicate with the SPX.SYS driver.
 Action         Make sure that the SPX.SYS file has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Check for a mismatch of driver versions. If the
                problem persists, contact your Novell Authorized Reseller.

 REQ1111: The SPX device handle cannot be closed. Error: <code>.

 Explanation    The SPDeamon cannot close the device handle. This may be an
                internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1112: The SPDaemon cannot wait on semaphore. Error:  <code>.

 Explanation    A DosSemSetWait call failed. This may be an internal program
                error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1113: System information segments cannot be obtained. Error: <code>.

 Explanation    The DosGetInfoSeg call failed. This may be an internal program
                error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1114: Priority for the lock thread cannot be set. Error: <code>.

 Explanation    The DosSetPrty call failed. This may be internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1115: The SPX driver cannot be accessed. Error: <code>.

 Explanation    The SPDaemon was not able to access SPX.SYS through the call
                gate.
 Action         Make sure that the SPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Also check for a mismatch of driver versions; then
                try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1116: Priority for an AES thread cannot be set. Error: <code>.

 Explanation    The DosSetPrty call failed. This may be an internal program
                error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1117: Priority for a watchdog thread cannot be set. Error: <code>.

 Explanation    The DosSetPrty call failed. This may be an internal program
                error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1118: Priority for a session thread cannot be set. Error: <code>.

 Explanation    The DosSetPrty call failed. This may be an internal program
                error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1119: The SPXCALLS.DLL cannot register with the SPX driver.

 Explanation    The SPXCALLS.DLL cannot communicate with the SPX.SYS driver.
 Action         Check to see if the SPX.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Check for a mismatch of driver versions; then try
                again. If the problem persists, contact your Novell Authorized
                Reseller.

 REQ1205: The driver cannot initialize the CGroup Data variables.

 Explanation    Normally, key data variable are stored in the driver's CGroup
                for easy and reliable access. However, in this instance the
                variables could not be initialized due to a memory-related
                error.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ1206: The driver cannot configure SPX.

 Explanation    The driver in conjunction with the NWCONFIG.DLL failed to parse
                the NET.CFG file for the SPX parameters.
 Action         Make sure the format of the NET.CFG file is correct.

 REQ1207: The driver failed to get support hooks from the LSL or IPX.

 Explanation    SPX could not open or communicate with either the LINKSUP_
                (LSL.SYS) or the IPX_ (IPX.SYS) drivers. The most likely cause
                of this error is that one or both of these drivers has been
                improperly installed.
 Action         Make sure that the device drivers LSL.SYS and IPX.SYS have been
                properly entered in the CONFIG.SYS file. If so, check the
                messages displayed by the driver for any errors or warnings,
                and correct the problems indicated. Check for a mismatch of
                driver versions; then try again. If the problem persists,
                contact your Novell Authorized Reseller.

 REQ1208: The OS/2 version cannot be obtained; OS/2 v2.0 is assumed.

 Explanation    The DosGetVersion call failed (an internal program error), or
                the OS \2 version currently running is not v2.0 or later.
 Action         Make sure that OS/2 and the SPX.SYS driver are compatible
                versions. If this is not the problem, contact your Novell
                Authorized Reseller.

 REQ1209: The driver cannot get OS/2 DOS variables.

 Explanation    The SPX.SYS driver could not obtain either the system or local
                information segment. This may be an internal program error.
 Action         Try again. If the problem persists, contact your Novell
                Authorized Reseller.

 REQ1210: The driver cannot initialize the SPX call gate.

 Explanation    The SPX.SYS driver could not register a call gate with the
                LSL.SYS driver.
 Action         Make sure that the LSL.SYS driver has been properly entered in
                the CONFIG.SYS file. If so, check the messages displayed by the
                driver for any errors or warnings, and correct the problems
                indicated. Check for a mismatch of driver versions; then try
                again. If the problem persists, contact your Novell Authorized
                Reseller.

 REQ1211: The driver cannot allocate memory for SPX use.

 Explanation    The system does not have enough memory to run SPX.
 Action         Try adding RAM, reducing your configuration options in the
                CONFIG.SYS file (for example, reducing the size of DIRCACHE),
                removing optional device drivers from the CONFIG.SYS file, and
                freeing up some hard disk space by deleting unnecessary
                programs. If you are using multiple disk partitions, consider
                moving the OS/2 swapper file to a larger partition. Disk
                compression utilities may also be available that can help
                resolve this problem. After completing these actions, shut down
                OS/2; then reboot the system. If the problem persists, contact
                your Novell Authorized Reseller.

 REQ1301: The application cannot initialize named pipes.

 Explanation    The application could not open or communicate with the
                NMPIPE.SYS driver. Most likely, the NMPIPE.SYS driver is not
                entered in the CONFIG.SYS file.
 Action         Make sure that the NMPIPE.SYS driver has been properly entered
                in the CONFIG.SYS file. If so, check the messages displayed by
                the driver for any errors or warnings, and correct the problems
                indicated. If the problem persists, contact your Novell
                Authorized Reseller.


ΓòÉΓòÉΓòÉ 19. Troubleshooting Tips and Where To Go for Help ΓòÉΓòÉΓòÉ

Troubleshooting Tips and Where To Go for Help

Troubleshooting Tips

Verify that:

Γûá Frame types are set the same on the workstation and the server.

Γûá Board configurations and software parameters match.

Γûá NET.CFG parameters, such as name context, match your NetWare system
configuration.

Γûá Network cabling is within IEEE specifications and is properly connected and
terminated.

Γûá All network software is the most recent version available.

Where To Go for Help

Novell offers a varitey of support, including

 Γûá Novell Technical Support
 Γûá NSEPRO
 Γûá Your Novell Authorized Reseller
 Γûá NetWire on CompuServ
 Γûá Novell Application Notes

 For more information, call 1-800-NETWARE.

 For more information about OS/2, contact your IBM representative.


ΓòÉΓòÉΓòÉ 20. Architecture Diagrams ΓòÉΓòÉΓòÉ

Architecture Diagrams

These diagrams provide a technical overview of NetWare Client for OS/2*.

They can help you understand what components are used for the various functions
NetWare Client for OS/2 performs (for example, which components are used to
support Named Pipes).

Specifically, the diagrams illustrate

ΓûáThe major functions of NetWare Client for OS/2 components

ΓûáThe different components of NetWare Client for OS/2

ΓûáThe relationships between components

NoteYou do not need to manually load the components shown in the diagrams.
Select the settings you want in the NetWare Client for OS/2 installation
program, and the correct components will be loaded.

To change the settings later, run the installation program again. Topics and
architecture diagrams

NetWare Requests from OS/2 Sessions

NetWare Core Protocol Requests

File System Requests

Protocol Requests from OS/2 Sessions

IPX-Only Requests

SPX Requests

Named Pipes Server Requests

Named Pipes Client Requests

NetBIOS Requests

NetWare Requests from DOS/MS Windows Sessions

DOS/MS Windows NetWare Core Protocol Requests

DOS/MS Windows File System Requests

Protocol Requests from DOS/MS Windows Sessions

DOS/MS Windows SPX- or IPX-Only Requests

DOS/MS Windows Named Pipes Client Requests

DOS/MS Windows SQL Client Get Server Requests

DOS and MS Windows NetBIOS Requests

NetBIOS Submit Requests Using Only Novell NetBIOS Driver with Extended Services
Loaded

Sharing a Network Board

NetWare Client for OS/2 and IBM Software Using ODINSUP to Share a Network Board

NetWare Client for OS/2 and IBM Software Using LANSUP to Share a Network Board


ΓòÉΓòÉΓòÉ 20.1. NetWare Core Protocol Requests ΓòÉΓòÉΓòÉ

NetWare Core Protocol Requests

NetWare Core Protocol (NCP) requests go directly to the NetWare server without
going through OS/2.

Some NetWare utilities issue this kind of request. These requests are usually
accompanied by file system requests.


ΓòÉΓòÉΓòÉ 20.2. File System Requests ΓòÉΓòÉΓòÉ

File System Requests

File system requests are handled by OS/2 before being passed on to NetWare
Client for OS/2. Any program which manipulates files on the network makes this
kind of request.

These requests are always accompanied by NetWare Core Protocol requests.


ΓòÉΓòÉΓòÉ 20.3. IPX-Only Requests ΓòÉΓòÉΓòÉ

IPX-Only Requests

IPX requests are issued by IPX applications, including NetWare Client for OS/2.


ΓòÉΓòÉΓòÉ 20.4. SPX Requests ΓòÉΓòÉΓòÉ

SPX Requests

SPX requests are issued by SPX applications. Some NetWare print utilities and
API calls use SPX.


ΓòÉΓòÉΓòÉ 20.5. Named Pipes Server Requests ΓòÉΓòÉΓòÉ

Named Pipes Server Requests

Named Pipes server requests are made by Named Pipes distributed application
servers.


ΓòÉΓòÉΓòÉ 20.6. Named Pipes Client Requests ΓòÉΓòÉΓòÉ

Named Pipes Client Requests

Named Pipes client requests are issued by Named Pipes distributed application
clients.


ΓòÉΓòÉΓòÉ 20.7. NetBIOS Requests ΓòÉΓòÉΓòÉ

NetBIOS Requests

What is NetBIOS

NetBIOS is a "device-independent" protocol that lets applications use network
boards without knowing the specifics of how the drivers for those boards work.

NetBIOS applications issue NetBIOS commands which are routed to a specific
network board driver. That driver handles the transmission of NetBIOS packets
over the network.

What is the Novell NetBIOS Emulator

Novell provides a NetBIOS emulator that allows applications running on an
IPX-based network (such as NetWare) to communicate using NetBIOS.

This NetBIOS emulator encapsulates NetBIOS packets inside of IPX packets. Then
an ODI driver handles transmission of the IPX packets over the network.

While your NetBIOS application communicates using NetBIOS commands, the NetBIOS
emulator actually transmits IPX packets.

The Novell NetBIOS emulator can only communicate with other emulators that use
IPX.

For example, if you have one workstation running the NetBIOS emulator and
another workstation running IBM's NetBIOS, the two workstations cannot
communicate.

However, the NetBIOS emulator can run on the same OS/2 workstation as other
NetBIOS implementations, including the NetBIOS provided with IBM Extended
Services or LAN Services. Or, the NetBIOS emulator can run by itself.

NetBIOS requests are issued by applications which use Novell NetBIOS emulation.

If Extended Services or LAN Services is installed, requests follow a different
path.

NetBIOS Submit Requests Using Only Novell NetBIOS Driver

NetBIOS Submit Requests Using Only Novell NetBIOS Driver with Extended Services
Loaded

NetBIOS Submit Requests Using Either Novell or IBM NetBIOS Driver with LAN
Services Loaded

NB30 NetBIOS Requests Using Either Novell or IBM NetBIOS Driver with Extended
Services Loaded


ΓòÉΓòÉΓòÉ 20.8. NetWare Requests from DOS/MS Windows Sessions ΓòÉΓòÉΓòÉ

NetWare Requests from DOS/MS Windows Sessions

When you select support for virtual DOS sessions in the NetWare Client for OS/2
installation program, the installation program adds lines to the CONFIG.SYS
file to load the VIPX and VSHELL components.

The NETWARE_RESOURCES and VIPX_ENABLED properties are also created and added to
the DOS Settings notebook of all DOS and Windows icons.

These properties allow you to choose global support, private support, or no
network support for each session.

Γûá If you choose global support, VIPX and VSHELL are enabled for the session.

Γûá If you choose private support, VIPX is enabled, VSHELL is not enabled, and
you can manually load NETX.EXE

Γûá If you don't load NETX.EXE, you receive IPX- and SPX-only support.

Γûá If you choose VIPX_ENABLED OFF, then no NetWare support is loaded.

VIPX must be enabled for either global (using VSHELL) or private (using NETX)
sessions to work.

DOS/MS Windows NetWare Core Protocol Requests

DOS/MS Windows File System Requests


ΓòÉΓòÉΓòÉ 20.9. DOS/MS Windows SPX- or IPX-Only Requests ΓòÉΓòÉΓòÉ

DOS/MS Windows SPX- or IPX-Only Requests


ΓòÉΓòÉΓòÉ 20.10. DOS/MS Windows Named Pipes Client Requests ΓòÉΓòÉΓòÉ

DOS/MS Windows Named Pipes Client Requests.


ΓòÉΓòÉΓòÉ 20.11. DOS/MS Windows SQL Client Get Server Requests ΓòÉΓòÉΓòÉ

DOS/MS Windows SQL Client Get Server Requests


ΓòÉΓòÉΓòÉ 20.12. DOS and MS Windows NetBIOS Requests ΓòÉΓòÉΓòÉ

DOS and MS Windows NetBIOS Requests


ΓòÉΓòÉΓòÉ 20.13. DOS and MS Windows NetBIOS Requests with Extended Services Loaded ΓòÉΓòÉΓòÉ

DOS and MS Windows NetBIOS Requests with Extended Services Loaded


ΓòÉΓòÉΓòÉ 20.14. Sharing a Network Board ΓòÉΓòÉΓòÉ

Sharing a Network Board

How ODINSUP Works

ODINSUP translates NDIS transmissions from Extended Services or LAN Services
into a form that complies with the ODI drivers.

ODINSUP also translates transmissions received from the network into a form
readable by Extended Services and LAN Services.

ODINSUP functions like a default protocol stack, meaning that it accepts
requests from the Link Support Layer (LSL) that are not specifically marked for
another registered protocol (such as IPX or TCP/IP).

When it receives requests, ODINSUP passes them on to the NDIS protocol stack.

ODINSUP allows IBM's Protocol Manager (found in Extended Services and LAN
Services) to communicate with a network board without having to be aware of the
details of transmission on that board (such as frame type).

Instead, the details are handled at the ODI driver level and then transmissions
are passed on to the Link Support Layer, which in turn passes them on to the
correct protocol stack or to ODINSUP.

ODINSUP translates the request to a form understood by Protocol Manager.

"Using ODINSUP and LANSUP" explains more about using ODINSUP. ODINSUP is for
using ODI drivers. LANSUP is for using NDIS drivers.

NetWare Client for OS/2 and IBM Software Using ODINSUP to Share a Network Board

NetWare Client for OS/2 and IBM Software Using LANSUP to Share a Network Board